Comment 9 for bug 48627

I believe what is proposed is avoiding to fix the real problem.
I believe one of the real problem is at:
adept-2.1.2ubuntu27/adept/updater/app.cpp where we have:

    aptFront::Manager m;
     m.setProgressCallback( m_progress->callback() );
     m.setUpdateInterval( 100000 );
     try {
         m_stack->raiseWidget( m_progress );
         m.download();
         m_stack->raiseWidget( m_commitProgress );
         m.commit();
     } catch ( exception::OperationCancelled ) {
     } catch ( ... ) {
         KMessageBox::sorry(
             this, i18n( "There was an error commiting changes. "
                         "Possibly there was a problem downloading some "
                         "packages or the commit would break packages. "
                         ),
             i18n( "Could not commit changes" ) );
     }

My feeling is that m.commit() make a new instance of dpkg installed all the packages downloaded in m.download().
But when any error happen in that, KMessageBox::sorry is shown, but I did observed that while it is shown, I can
see the packages continue to be installed in details window.

So if one would wait for the packages for being all installed before clicking Ok, there would no problem.
But if you click ok button before all packages finished installing, adept quit. While quitting, it make the spawn
dpkg process to quit too, while it is still installing stuff. This make it kept a lock on package database.

My suggestion would be to add some code to wait for the m.commit() to finish just after the sorry MessageBox, rather
than quit right away.

But I am still searching the code of aptFront::Manager to better understand what is still just an hypothesis.
And I am afraid to not know enough to code to 'wait for the m.commit() to finish'.