[Aptitude-devel] Plans for aptitude 0.5.0 - 0.6.0.

[Daniel Burrows]

On Wed, Oct 29, 2008 at 09:29:50AM -0700, Daniel Burrows <dburrows at debian.org> was heard to say:
> On Fri, Sep 05, 2008 at 08:15:48PM -0700, Daniel Burrows <dburrows at debian.org> was heard to say:
> >   Major TODOs for 0.6.0:
> > 
> >     * Show dpkg interaction inside the program instead of in the
> >       controlling terminal.
> > 
> >       + For 0.5.0: pop up dpkg in a new tab.  Estimated hack time: 4-8
> >         hours; we just need to integrate support for libvte.
> 
>   That was a wildly optimistic estimate.  The main problem was that I had
> to completely redesign the entire process of invoking dpkg, bottom to top,
> in all frontends, in order to acheive this in a reasonable way.  I also,
> along the way, fixed the GTK+ frontend to run its downloads in a
> background thread.  The new code should be a lot more stable, plus it
> runs dpkg in a tab!

  One problem that's left: it looks like the new code crashes sometimes
after downloads.  The problem seems to be that I used slots to
communicate between background and foreground threads; I forgot how
massively unsafe slots are in the presence of threads.  The biggest
problem is that when you connect to an object's method, destroying that
object will mutate the slot connection (like COME FROM but with threads
and objects, whee!).

  We need to go over the download code and enforce a strict separation
between foreground and background code, so that sigc structures are only
ever accessed from one thread.  Inter-thread communication needs a
non-slot callback class (like the "event" class used in cwidget), and
much attention will have to be paid to lifetime issues.

  A starting point will be to merge some older code into download_thread,
because it used to be non-slot-based (I think this is why ... d'oh).
Also, probably post_event() in the GUI should take a cwidget event object
instead of a slot.

  Once this is done, I think we're ready to put out a build into
experimental.

  Daniel