David Kalnischkies

The project as-is was moved to the Debian GSoC folks and accepted there. I had a great (and productive) summer and all you might want to know can be found in my blog and in the aftermath i wrote for the debian wiki.

Contact information

• Your Name: David (Sascha) Kalnischkies

• Email Address: kalnischkies@gmail.com

• IRC nickname: DonKult

• Launchpad ID: donkult
• Skype username: none - to be solved by this Idea!¹

• Webpage/blog: http://donkult.wordpress.com/

• College-University: TU Darmstadt (Hesse, Germany)
• Major: Computer Science (fourth semester)

¹ okay, i don't like skype myself so it will not be solved for me, but it serves me well as an example for the mess a user runs into without MultiArch (and skype is even one of the easier messes).

Project

• Project Name: MultiArch support in APT

• Project Description: While hardware like 64bit processors are perfectly able to execute also 32bit commands the current software stack doesn't allow it in a clean and easy way as most low level tools are not MultiArch enabled.

  • This project will focus on enable APT (and through libapt also the upper stack applications like 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.

• If you would be willing and able to do other projects instead, which ones?
  • It sounds a bit rude, but: None.
• Why did you like this idea?
  • Unfortunately some software isn't available for all architectures: Be it a commercial application or free software which can't be compiled on the native architecture (yet). Until now a user have to jump through many loops to be able to use this software if it is not available for his architecture. The other big thing this spec partly solves as a first step is a good and easy way to cross compile if native is not an option (e.g. my phone is too slow to compile stuff in a reasonable time)
• Give us details about the milestones for this project

  1. 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.

  2. 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…

  3. A very important aspect beside the implementation is a decent user documentation as an undocumented feature doesn't really exists…

  4. 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…)

  5. Cache generation needs to be improved:
     1. The "in-generation" cache should be able to grow dynamical (MMap ran out of room)

     2. My current MultiArch patch adds a LOT of (implicit) dependencies - reducing the amount should speed up resolving and saves space

     3. 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…)

  6. 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.
  7. Try to assist every user of the APT library in making their applications multiarch aware and/or compatible.
• Please describe a tentative project architecture or an approach to it:

  • The approach can be very easily described: Try hard to fix old bugs and introduce new features faster than users can report new bugs/feature requests. So the taken approach is definitely not the "Waterfall model" and can't be modeled easily that way. The points listed in the previous section are therefore only an open list of mile not written into stone - they need to be constantly adapted to reflect and achieve the ultimate goal: the user doesn't need to care about if a package is compiled for amd64 or for i386 - just let APT install and let it work out all the boring details.

• Why will your proposal benefit Ubuntu?

  • The whole MultiArch thing is in discussion for quite some time now and was a release goal for Debian squeeze and Ubuntu lucid. For both the goal was dropped for this cycle but it is definitely back on the white board for squeeze+1 and maverick. Beside the various user perspectives i described above we have also the developers who waste quite a bit of time preparing pseudo multiarch (or better biarch) packages like ia32-libs which are (frankly speaking) a bloody hell to maintain.

Open Source

• Please describe any previous Open Source development experience

  • I am "only" involved in APT development for ~ nine months now with mostly small to medium bugfixes and feature implementations and bug management (mostly in debbugs). All the glory details can be found in my branch and/or the changelog.

• Why are you interested in Open Source?
  • I "just" thing it is the way to go. I profited a lot from the possibility to look at the source code of application X to demystify it and learn something new but also to be able to adapt it to my needs and last but not least by the steady growing helpful communities around them.

Availability

• How long will the project take? When can you begin?

  • In regards to the MultiArch, i started a while after the last UDS in Dallas 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 and a lot (if not all) subgoals listed above should be implemented. In the more general aspect a software project like APT is never really complete, but which project is really finished anyway?

• How much time do you expect to dedicate to this project? (weekly)
  • In total good old full-time (40h) - maybe a bit less in the first (lectures) and a bit more on the second (no-lectures) half, but i haven't decided yet which if any lectures to drop in favor of GSoC as i have only theoretical time estimates at the time of writing this.
• Where will you based during the summer?
  • At home, Erbach (Rheingau) and at the uni - both in Hesse, Germany (GMT + 2)
• Do you have any commitments for the summer? (holidays/work/summer courses)
  1. my "normal" semester duties like a few lectures from 12.04. to 16.07. (see above)

  2. uds-m participation - as you might know - from 09.05 to 15.05

  3. as youth group leader from ~ 31.07. till 06.08. on "holidays"
• Please designate a back up student (in case you need to withdraw your application)

  • I am afraid that none is available to replace me as the general interest on lower level applications like APT is as low as the level of the application - but it would be great if someone could convince me of the opposite.

Other

• Have you ever participated in a previous GSoC? (describe your project)
  • No.
• Have you applied for any other 2010 Summer of Code projects? If yes, which ones?
  • No.
• Why did you apply for the Google Summer of Code ?

  • The last half year i have invested a serious amount of time to work on MultiArch and a lot of other features - and while this is/was a lot of fun it unfortunately doesn't pay my bills, so in the next time frame i have two options: Start to flip a few burgers or proceed in flipping bytes in APT. It should be obviously which option i would prefer. Beside the little € symbols in my eyes it is also a good chance to actually work on a real and big project to apply the theoretical knowledge i should have accumulated while studying and giving some of the time back i save every day while using software prepared for me by others in the community.

• Why did you choose Ubuntu as a mentoring organization?

  • The Godfather of Package management - Mr. Michael Vogt - is employed by Ubuntu and is most likely the best (if not the only) Mentor available for APT ~ further more Steve Langasek is one of the drivers behind the MultiArch spec and hopefully also available for resolving outstanding MultiArch problems. On the more personal front i have started my linux career with ubuntu and the "Gutsy Gibbon" which was able to help me in my "contact!" months - i left the stable wagon by the end of hardy to dig deep into the dark reams of the "mother" debian and her unstable branch. I haven't regret the step myself as i like to test new stuff, but this is obviously not a system manageable for not so techy friends/family members so i am still in close contact with Ubuntu and once in a while i am asked: "Heh, you have installed this shiny new non-windows/mac system on my pc - works good so far, i can browse the net, email, watch a video or two, but i recently installed skype…" and the story should continue with "… and everything still worked - not like in the past days as i faced what you always called 'bloody dependency hell'. This new system is simply awesome! Thanks a lot!".

• Why do you want to participate…

  • I guess i have answered that already to full extend but to drop some keywords: OpenSource, give something back, gather experience, "do something useful…(… and get even paid for it)", helping the Debian family to acquire world domination, prove that even my cat could install skype on her laptop

• … and why should Ubuntu choose you?

  • My name is "David" - as we all know this means "Beloved" - so why not i ask? In the unlikely event that i haven't already convinced you with this fact reading my at times lengthy answers to question above should indicate that i am really passionated and good-humored student who is willing to learn, to invest a lot of time and has proven to deal well with small "goliaths" in the "beloved" APT already.

If still not convinced feel free to drop me a line (or two).