dpkg – Page 10

Quick news: dpkg, collab-maint, alioth and the future

July 22, 2010 by Raphaël Hertzog

Dpkg got rid of Perl

Let’s start with the interesting part and the great news: dpkg 1.15.8 (to be uploaded soon) will no longer need perl! After my changes to rewrite update-alternatives in C, Guillem recently pushed the rewrite of dpkg-divert/mksplit in C. Please test it out (binary package for i386 or .dsc).

This is rather exciting news for those who would like to use dpkg in embedded contexts. And it’s great to see this completed in time for Squeeze. In Squeeze+1, we might go one step further and merge cdebconf, the C replacement for debconf.

I got rid of some recurring administrative tasks

I have been administrating the Alioth server since its inception (see the announce I sent in 2003) but I’m no longer enjoying the day-to-day administrative work that it represents. That’s why I just retired from the team. We recently recruited Tollef Fog Heen so the number of admins is still the same (that said, Alioth could benefit from some more help, if you’re a DD and interested, drop a mail to admin@alioth.debian.org or come to #alioth).

Same goes for the collab-maint project. I have dealt with hundreds of requests to add new contributors to the project since it’s the central repository where all Debian developers have write access and where they put the VCS for their packages that do not belong to a more specialized team. The new administrator that will approve the requests is Xavier Oswald and he’s doing the work under the umbrella of the New Maintainer’s Front Desk.

The future

I will continue to spend the same amount of time on Debian, the time freed will quickly be reallocated to other Debian and free software related projects. In fact, I even anticipated a bit by launching Flattr FOSS last week but that’s a relatively simple project. 🙂

The other projects that will never all fit in the freed time: I want to spend more time working on dpkg. I do plan to blog more often too, but I’m sure you’ll notice that yourself soon. I would like to see my Debian book translated into English (another post coming on the topic sometimes soon). In my dreams, I could even start yet another software project, I have some ideas that I really would like to see implemented but I don’t see how that could fit in this year’s planning… unless I can convince someone else to implement them! Maybe I should blog about them.

Rewriting update-alternatives in C

May 27, 2010 by Raphaël Hertzog

Among the goals listed in dpkg’s roadmap, there’s the C rewrite of the remaining perl scripts provided by the dpkg binary package (dpkg-dev is not concerned, it will remain a collection of perl scripts). Of the remaining scripts, update-alternatives was the largest piece of code (~1100 lines of perl) and I started converting it to C a few weeks ago (based on preliminary work of Guillem). It’s now 2200 lines of C…

Thanks to the relatively extensive test-suite that I wrote last year, I’m relatively confident that this new update-alternatives won’t break your system. That said, it still needs some real-life usage to ensure everything is really ok (and users actively trying to break it are even better). Thus I would be glad if you could try it out ( binary package for i386 or .dsc) and report back to debian-dpkg@lists.debian.org.

The rewrite of the 2 other remaining scripts is almost completed in a branch of Guillem. Hopefully this can be our last project completed in time for Squeeze as far as dpkg goes. It would be a great achievement for people that would like to use dpkg in embedded environments and avoid perl due to its size.

Note: nobody sponsored that work. But it’s not too late 🙂

Debian related goals for 2010

January 9, 2010 by Raphaël Hertzog

Here’s stuff that I’d like to do this year, more or less by decreasing order of importance:

translate my Debian book into English and get it published;
finish the cleanup of the perl API in dpkg-dev in order to create libdpkg-perl;
create dpkg-buildflags to export default build flags that packages should use (and get rid of the code setting those environment variables in dpkg-buildpackage), needed to properly fix #489771;
ensure the new source formats continue to gain acceptance by improving whatever is needed;
design a generic vcs-buildpackage infrastructure to be integrated in dpkg-dev. This design will probably happen through a DEP (Debian Enhancement Proposal) to ensure we have had proper discussion before someone gets to the implementation;
continue fixing dpkg bugs faster than they are reported;
enhance our infrastructure to ease interaction between contributors and to have a better view of how each package is maintained (see my last blog entry on this topic);
update the developers-reference where needed and fix some of the numerous wishlist bugs;
rewrite in C the last perl scripts provided by the dpkg binary package (update-alternatives/mksplit mainly, for dpkg-divert there’s a preliminary patch available already) so that it’s easier to build a minimal system without perl-base;
integrate the 3-way merge tool for Debian changelogs in dpkg-dev;

All of this probably doesn’t fit in my free time (being a father since last month does not help increasing my free time :-)), so if you’re interested in seeing one or more of those projects completed, and if you know some person/company that could sponsor them, get in touch with me!

5 years of Freexian

January 5, 2010 by Raphaël Hertzog

5 years ago I founded my own company Freexian SARL with the goal to make a living out of my free software experience. I marketed the company as being specialized on the Debian distribution in the hope to combine my Debian work and my professional work.

Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration.

However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I’m able to contribute something back to Debian, it’s usually not in areas that I care about.

My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it’s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment — either in the blog or by mail).

That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don’t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows… maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome!

Tags

Recent Posts