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

[David Kalnischkies]

On Tue, Nov 29, 2011 at 08:21, Sven Joachim <svenjoac at gmx.de> wrote:
> On 2011-11-29 01:44 +0100, David Kalnischkies wrote:
>
>> In that vision, the biggest problem for aptitude to face currently are
>> problems it has with multiarch. I implemented it in APT in a way i hoped
>> it would make it possible to sell multiarch as singlearch to the frontends.
>> This (surprisingly) works for a lot of cases, but from the folks from ubuntu
>> i heard different stuff about aptitude performance in multiarch environment
>> (we don't have it in debian yet, so i rely here on chit-chat - bear with me)
>> so i guess certain codepaths depend on singlearch more than others do.
>
> Performance is actually the least of the problems, although there is of
> course a penalty with the number of available packages increasing by
> ~20000 per foreign architecture.  The following issues are much more
> severe:

Thanks for the information!
(And for the record, i meant with "performance" more the ability to work in
 multiarch in general - not the speed factor - but i see that the word choice
 was a misfortune one…)


> - Packages of foreign architectures are always considered "new", making
>  the "New Packages" section in the TUI totally useless[1].

That is to be expected, as they are new packages… ;)
For this kind of feature, it will be better to iterate over GrpIterator.
The name is a bit silly, but the idea is that it "groups" packages with
the same name but different architectures together.
"apt-cache pkgnames" uses it for example.
(This interface is in squeeze, too, in case you are about backports)

In fact that is the central concept of the MultiArch implementation
as it possible to decode MultiArch in a SingleArch problem then,
just the assumption that a packagename is unique isn't true anymore…


> - The architecture of packages is not exposed in the UI, leading to
>  confusion ("which version of libc6 is it I'm looking at now?").

That should be in theory as trivial as changing all occurrences of
Package.Name(); to Package.FullName(true);
The parameter true will enable pretty printing - hence for the
native (and all) architecture no architecture is shown.


> - If "Multi-Arch:same" packages get out of sync, aptitude finds no
>  solution at all in everyday situations like "aptitude safe-upgrade".

Most of the time, there is none in this case, as the dependency
is a pretty hard one between them - beside doing nothing of course.
I don't have an idea now why aptitude might have a problem here.


> - Conflict resolution seems to be entirely broken[2].

The implicit MultiArch dependencies (= breaks) are added explicitly
to the Versions, so they should look and feel like normal dependencies.
The idea was simple to avoid changing resolvers and that is mostly true:
APTs resolver needed one change as far as i remember: Self-conflicts need
to be ignored for the whole group, not only for the package itself.

Let me add that some bugs might be fixed by the newer libapt
resisting in experimental currently, as we had some bugs in the
cache creator responsible for creating all needed breaks and provides.


Best regards

David Kalnischkies