On Monday 02 July 2007 12:22:14 Paul Dufresne wrote:
> 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'.
I also believe that m.commit() is a synchronous call... so I believe that it
does wait for the m.commit() to finish. I could be wrong though.
On Monday 02 July 2007 12:22:14 Paul Dufresne wrote: 1.2ubuntu27/ adept/updater/ app.cpp where we have: llback( m_progress- >callback( ) ); rval( 100000 ); >raiseWidget( m_progress ); >raiseWidget( m_commitProgress ); :OperationCance lled ) {
> I believe what is proposed is avoiding to fix the real problem.
> I believe one of the real problem is at:
> adept-2.
>
> aptFront::Manager m;
> m.setProgressCa
> m.setUpdateInte
> try {
> m_stack-
> m.download();
> m_stack-
> m.commit();
> } catch ( exception:
> } 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'.
I also believe that m.commit() is a synchronous call... so I believe that it
does wait for the m.commit() to finish. I could be wrong though.
--
~ manchicken <><
(A)bort, (R)etry, (I)nfluence with large hammer.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Please avoid sending me Word or PowerPoint attachments. www.gnu. org/philosophy/ no-word- attachments. html
See http://