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 <[email protected]> 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 [email protected]. Depending on the specific idea [email protected] 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 _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
