[Aptitude-devel] About the status and plans for aptitude

[David Kalnischkies]

First of all: I hate you, guys!
One of my new year resolutions was to keep the bugcount of apt
below the bugcount of aptitude. Given that aptitude is only 3 bugs ahead
currently i fear i will miss it… and that's your fault!!!111eleven ;)

Seriously, i guess the odds are now against me, but i will at least try
to be a good underdog and provide a good fight for the glory of place 4
(and 3) in the list of packages with the highest bugcount…

Oh, and given that we properly share a few bugs/features feel free
to triage a bit in apt, too, if aptitude reports are boring. ;)
(or more likely: you want to reassign something)

So a more serious first of all: Welcome in the APT-family! :)


On Sun, Jan 15, 2012 at 04:52, Daniel Hartwig <mandyke at gmail.com> wrote:
> * Multiarch
>
> 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).

I was told that it tends to work correctly in many scenarios.
(the usual chit chat you know… some of the bugs are properly apts fault,
 too, as without a released dpkg i never had the chance to try my own code
 in real world multiarch scenarios, so quiet a few non-trivial bugs were
 included and properly a few are still in… but heh, who doesn't like busy
 waiting…)

As i said earlier in this thread for the resolver in APT it was the best
to reduce the problem with a few tricks to a single architecture problem.
I guess this is beneficial for aptitude, too, but i am not good at guessing.

Have especially an eye on Provides handling. debian-policy doesn't allow
versioned provides (in the sense that they have undefined behavior), but APT
allows them! And multiarch makes use of that as M-A: foreign is implemented
by provides. Also, as i noticed this week that implicit conflicts need to be
relaxed a bit to apply only on real packages, not on virtual ones.

Depending on how libapt is used you might be exposed to these kind of
"strangeness's" or you are not and these remarks scare the shit out of you…
So don't worry too much in case you don't know what i talk about here:
MultiArch has a small but step learning curve and not many people really
tried it, so you will be one of the few choosen ones. ;)

I am properly better at helping/guessing what went wrong if you have a
specific example. Feel free to have a look at apt/tests/integration/ the
bash scripts include a few simple multiarch tests maybe you can adapt
them for your own testing.


> 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.

Lets hope for the best.


> 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)

As i said earlier, feel free to bring any problem you might have with it
to the attention of deity at l.d.o. In general, if you have something for
(package manager) common-interest, feel free to post it there.
And/or join irc #debian-apt . Both are pretty low-traffic and not that
crowded but "thanks" to the "variety" of maintainers you will find the
maintainer of every big and not so big apt-related project in them - so
a few seats are already reserved (and preheated) for aptitude crew. :)


> * Matching / search pattern handlers
>
> Not a major issue but there is a lot of room there for, e.g., removing
> redundancy.

I wrote while working on multiarch an abstraction for the commandline
parsing of packages/versions for the apt-* tools supporting tasks as well
as regex and selection of specific versions. Back then i thought it would
be cool to "backport" at least parts of aptitudes turing-complete(?) search
patterns and i still think it might be worthwhile. I just got distracted by
other stuff (= i couldn't sell that as a feature required for multiarch) and
problems like that i never had used them myself and that they seem to
be spread all over the place in aptitude, so if you have any pointers…

The code for this abstraction is in apt/apt-pkg/cacheset.cc (see the version
in experimental/bzr as i changed to even more heavy template usage).
Basically they are containers like std::set<pkgCache::PkgIterator> with
a few (static) methods for commandline parsing and stuff.

If you think this might be a good idea we can try to make it usable for
aptitude, too.


Best regards

David Kalnischkies