Name: David (Sascha) Kalnischkies
Background: 4th semester computer science student at the technical university of Darmstadt (Hesse, Germany, Europe, Earth).
Proposal: ?MultiArch in APT
Synopsis: Enable APT (and through libapt also the upper stack applications like synaptics, software-center and co) to resolve dependencies according to the MultiArch Spec and therefore enable the user to install non-native packages without the need of a developer to publish biarch packages as a dependency hack.
Benefits to Debian: The whole ?MultiArch thing is in discussion for a long time now and was a release goal in Debian as well as in Ubuntu for quite a while - i guess it will be a good thing to finally mark the ?MultiArch stuff as done in the next release(s) and support in APT for it should be a huge step forward to achieve this goal.
Project details: (the proposal description is from me, so you can do a mental copy&paste here if you want)
Project schedule: I started a while after the last Ubuntu Developer Summit in Dallas where the topic was discussed so i guess i can begin… yesterday? The project isn't finished now and will most likely not to full extend by the end of the summer - but the state should be releasable. In the more general aspect a software project like APT is never really complete, but which project is really finished anyway?
More detailed schedule please: It is hard to nail down a formal schedule here as i depend a lot on the feedback of others - so will be bugfixing a big part of the project as debugging dependency resolution isn't trivial and therefore consumes a lot of time in general and has obviously a higher priority than coding some stuff in the dark room… but i have also some "dark room" subgoals. The following is what i see currently as my "subgoals":
a prelimited patchset from me for ?MultiArch in APT is currently available in debian experimental. The main focus was the API/ABI part and as a second to enable (library) packagers to play/test ?MultiArch (in simulation) which should help in get some movement into the acceptations rate of the spec as we currently have a hen-egg-problem: few packages <--> No package manager support The result is a mostly untested and therefore a very fragile system: A (big) part of this project will be as such testing and "a bit" of bugfixing.
Implement and use apt-get and friends as a reference for all other wannabe package managers for "package universe, ?MultiArch and stuff". It would help nothing if we would have only theoretical low level support…
- A very important aspect beside the implementation is a decent user documentation as an undocumented feature doesn't really exists…
Debian ftpmasters intend to start dropping package metadata from Packages file. In the very same experimental upload of APT is support for splitting out Long Descriptions - as these waste (a lot of) space in ?MultiArch systems it would be good to see them dropped for the next release of Debian/Ubuntu. Someone should get in touch with both archive gatekeeper teams… (Follow-up out-of-spec idea: APT should provide facility for other applications to load additional packages related data together with the usual Packages file, e.g. debtags, review & ratings for software center…)
- Cache generation needs to be improved:
- The "in-generation" cache should be able to grow dynamical (MMap ran out of room)
My current ?MultiArch patch adds a LOT of (implicit) dependencies - reducing the amount should speed up resolving and saves space
Add a possibility to ignore information at cache generation step for package we will not need (also useful in non-?MultiArch usecases: An x-less server shouldn't waste his valuable time parsing gnome-package information…)
- The resolver is until now unchanged. That is good in general, but it is likely that special cases need special handling in the resolver, as we have many new negative dependencies (Breaks and alike). Time/Bugreports will tell.
- Try to assist every user of the APT library in making their applications multiarch aware and/or compatible.
Travel: As you can see in the next point, i am unfortunately not able to attend DebConf.
Other summer plans:
UDS-M participation from 09.05 to 15.05
- as youth group leader of my hometown from ~ 31.07. till 06.08. on "holidays" with "my" kids
Exams and other commitments:
my "normal" semester duties like a few lectures from 12.04. to 16.07, but nothing i could not drop if my time is better invested in the gsoc project
If you are not a Debian Developer: I am not a DD, which should be changed some time in the future i guess after i have learned more about the debian community which provide me since two years now with my main operation system. The world is much better than you know you can "apt-get install" whatever you like instead of hunting down everything yourself - and it becomes fabulous if you know it will work after the installation has finished (and proceed to work even after the next upgrade). It is only fair to reinvest a bit of the saved time.