[Soc-coordination] GSoC idea: aptitude package manager

[David Kalnischkies]

Hi Sam!

(sry, i meant to answer way earlier but got 'distracted' by exams and other
 nasty time-eaters like security bugs… :/ )

On Sun, Feb 26, 2012 at 05:07, Sam Lidder <sam.lidder at gmail.com> wrote:
> I was curious as to whether any of the developers on the aptitude
> development team would be participating as mentors for GSoC 2012. The

Good question, lets ask them. ;)
They are reachable on aptitude-devel at lists.alioth.debian.org.

Depending on the specific idea deity at lists.debian.org is also an interesting
place as this is the place for "general" package management development
related to APT to not constantly reinvent the wheel again and again for
every front-end.

So, depending on the idea the project might be "only" to implement something
in aptitude, but involves to great extend working on libapt, too -
but i guess you will see what i mean in a second.


> 1. As of now, when build dependencies of a package are installed,
>   aptitude marks them as being manually installed. And since there is
>   no command to remove build dependencies, one has to do some extra
>   work to remove them. A solution to this would be to implement some
>   sort of '{remove,purge}-build-dep' command.
>
>   I believe this would be useful for anyone who likes to contribute
>   to/tinker with debian packages as it would allow them to easily
>   manage build-dependencies on their system. It would also make sense
>   to have it since a user would probably expect the ability to reverse
>   the build-dep operation to be built-in.

apt-get nowadays sports a (default off) APT::Get::Build-Dep-Automatic
option to mark build-deps as automatically installed. aptitude could
add that, too, but personally i think that is not the right direction.

This is one of the code pieces not in libapt and therefore reimplemented
in each front-end. And in each front-end implemented as a hack.
The obvious problem with this is that aptitude not only misses the
previously mentioned option, but also e.g. changes for cross-building
with the introduction of multiarch. So a proper project would it be to
fix the shortcomings in libapt leading to these hacks, write a proper
implementation in libapt and use it in the front-ends.
It's an idea we discussed and hope to finally find the time to write
it down properly really soon now(TM).

But your idea seems to have an interesting spin to it non-the-less:
Am i understand you right, that you want something like a dummy
package holding these auto-installed build-deps back as long as
this dummy is installed?


> 2. Aptitude doesn't have a 'source' command, like apt-get, to download
>   the source files of a package. After some searching I came across
>   this bug report:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=46889 , which
>   addresses the issue. It seems that the final decision was that the
>   feature wouldn't add anything more than 'apt-get source', but I think
>   adding this would provide a more consistent user experience for those
>   switching over from apt-get. Although I can understand why this might
>   be seen as redundant and adding unnecessary complexity, since the
>   functionality already exists somewhere else.

The bug-number is wrong, but i can imagine whats written there.
Question here in the end boils down to: Do we want to have aptitude as
a drop in replacement for apt-get and friends (apt-cache, …) or is it
'just' providing a different interface for package management and leave
the rest to the lower level. The code in apt-get for it is (surprisingly)
complex and some parts of it would really be better in the library, too,
but my personal take is that aptitude shouldn't gain such an option.
Reimplementing wouldn't be nice - and reusing apt-get code by just calling
it means that you don't get the usual 'aptitude' feeling in the output,
which might be a bit confusing/strange.


> It seems like this would be a great way to introduce interested students
> to the project so that they can continue to contribute code even after
> the event is over.

Never say that in public, but that is the evil plan behind GSoC.
(imagine a dark, evil laugh here) ;)

The real beneficiary is the student though as GSoC provides you
with way more benefits than just a pill of money…


Best regards

David Kalnischkies, GSoC2010 student and APT team member