[Soc-coordination] GSoC idea: aptitude package manager

Sam Lidder sam.lidder at gmail.com
Sun Feb 26 04:07:11 UTC 2012


I was curious as to whether any of the developers on the aptitude
development team would be participating as mentors for GSoC 2012. The
following are some ideas I thought could be implemented in the package
manager as part of a project:

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.

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.

I'm guessing that these ideas alone aren't enough to merit them being an
entire SoC project, so I was thinking maybe other bugs or features on
the wishlist could also be added as long as they fit within the time
scope of the project. Since I don't have any experience with the
aptitude code-base, I was hoping some devs could offer more insight.

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.

Sam Lidder

More information about the Soc-coordination mailing list