[Aptitude-devel] About the status and plans for aptitude
mandyke at gmail.com
Sun Jan 15 03:52:56 UTC 2012
On 15 January 2012 03:06, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> Hi Diggory, welcome aboard,
> 2012/1/14 Diggory Hardy <diggory.hardy at gmail.com>:
>> Unlike Christian and Axel I do have C++ skills, so maybe I can be
>> useful somewhere.
>> So how might I best be of use?
> Daniel Hartwig actually investigated and gave some thought to the
> areas that need improvements, e.g. to cope with multi-arch
> requirements or refactoring and fixing some areas causing many
> Maybe he can share his thoughts in this list soon, so people can start
> picking tasks.
A rough coredump:
* Build infrastructure
Currently autotools (which I have a certain fondness for), but needs a
fair amount of maintenance. Could optionally move to a different
system as another poster mentioned.
* Dependency resolver
Lots of bug reports, some of them not too useful. There are lots of
situations that still seem to cause aptitude trouble, but I have not
looked in to this at all.
* Group policy / tree view
The biggest concern here is that there are problems when a package has
multiple versions available and/or should be placed in to several
groups instead of one. The current code basically treats all
available versions of a package as a single entity, even though this
can result in incorrect grouping.
The bug that brought this to my attention  involved a package
changing from non-free to main between releases -- the package
appeared only under non-free.
A more detailed note about the issue is available  on another bug
about grouping by origin server. I no longer consider the proposed
solution in the footnote to be adequate -- this is a very large task
and needs to be done thoroughly, especially for excellent multiarch
support (by-arch grouping policy should not produce incorrect results
for packages in multiple archs).
Aptitude has no support for multiarch setups.
A certain derivative has already shipped with m-a enabled and they are
receiving a number of bug reports against aptitude concerning this
(apparently no one told their users not to use aptitude + m-a).
Judging by the ongoing effort from the dpkg and apt teams and interest
from other parties, Wheezy is probably going to have m-a support also.
I am yet to thoroughly investigate all the work required, however, it
is certainly possible to have some support in aptitude ready for the
freeze (proposed for June IIRC).
IMO, this will require:
- a couple of people to investigate and devise an action plan
- (the same) couple of people to develop the changes according to that plan
- *testers* across many architectures and m-a/non-m-a setups
At the very least, aptitude should become aware of multiarch packages
and this means support for libapt-pkg's GrpIterator.
I plan to get started on this immediately after finishing the few
things I am currently working on (i.e. Real Soon Now)
* Matching / search pattern handlers
Not a major issue but there is a lot of room there for, e.g., removing
Also a number of bugs  where the patterns don't interact the way
that one would expect, etc..
This is something that I plan to look at post-multiarch as I
personally feel that at least the grouping policies (tree view code)
could benefit greatly from being implemented in a language well-suited
to handling trees and lists in a general way -- i.e. Scheme or
Of course, aptitude involves a decent amount of code with many places
to work on. It is also quite modular, so one can happily work on,
e.g., the group policy code without knowing about the dependency
Those interested in bug triage or fixing minor issues can see my
recent post on usertags  which may be of assistance (bugs I have
usertagged are, generally, already triaged).
More information about the Aptitude-devel