Re: aptitude plans for the squeeze cycle
Daniel Burrows <firstname.lastname@example.org> writes:
> On Sun, Aug 16, 2009 at 02:41:08PM +0200, Marc Brockschmidt <email@example.com> was heard to say:
>> As announced on dda [RT1], we want to get an impression when releasing
>> Squeeze is feasible. We have proposed a (quite ambitious) freeze in December
>> 2009, and some developers have noted that their planned changes wouldn't be
>> possible in this time frame. So, to find out when releasing would work for
>> most people, it would be great if you could answer the following questions:
>> Do you have any big changes planned? How much time would they take, and
>> what consequences are there for the rest of the project?
> The main thing is that I want to get aptitude 0.6.0 into squeeze. In
> addition to some general fixes and improvements, the dependency solver
> should run five times faster on large problems than the current release
> of aptitude does. Hopefully this will mitigate the problems that I
> heard about with it taking a long time to calculate the upgrade to
> This means that I'll have to scale back my ambitions for that release.
> Specifically, I don't think the GTK+ frontend will be ready to be the
> default interface by December, so I've decided to focus on tying up
> loose ends and getting a build put together where the GTK+ code is an
> experimental add-on, not the default package (which mostly comes down
> to adjusting package dependencies and alternative priorities).
> I'm currently finishing up some code to cache data that's been
> downloaded for display in the UI, such as screenshots and changelogs.
> I also want to disable the full-text search of package descriptions
> by default; user feedback on that change has been uniformly negative.
> Once those changes are in and tested, I think I'll be ready to
> release 0.6.0.
>> How many "big" transitions will the upcoming changes cause? When should those
>> happen? Can we do something to make them easier?
> I don't expect aptitude's changes to impact many other packages.
> The changes mostly fall into a few categories:
> (1) New GTK+ interface: purely a UI change, and won't be installed by
> default in 0.6.0.
> (2) New searching code: as noted above, the full-text search will be
> switched off. The whole search engine has been rewritten from
> scratch; however, the search language should be the same as it
> was before.
> (3) Dependency solver optimizations: should be transparent to users.
> (4) Dependency solver enhancements: tighter constraints can be
> placed on what the solver returns, and the solver's treatment of
> particular packages can be overridden in /etc/apt/apt.conf.
> Should not impact other packages, except that it makes it possible
> to give hints to the resolver (this could be used to, e.g.,
> provide a recommended apt.conf stanza to make the upgrade smoother
> and avoid known resolver problems). If the release team would
> like different hints than the few that are available currently, I
> would be happy to add some more knobs here.
> (5) General enhancements and bugfixes: I don't expect that these will
> have an impact on other software.
Any plans to work with Steve Langasek on the multiarch proposal? That
would be a rather big change as well.