LCA: The state of Debian

The Debian miniconf is one of the oldest of linux.conf.au traditions. This year, Martin Krafft was the person who - with short notice - got to lead off this gathering with the "state of Debian" talk. Debian, as always, is an active project, and it seems that much is going well.

The Debian security team has grown over the last year. Martin noted that Debian, for all practical purposes, had no security support for a period after the Etch Sarge release. Those days are over, though, and Debian's security support is, once again, solid. There is now good security support for the testing distribution as well; in fact, testing updates often come out before those for the stable distribution. That result comes from the fact that testing updates do not need to support all architectures and there are fewer embargo issues.

The upcoming Lenny release, it was noted, will have implemented most of the features called for in the security-hardening specification.

The state of translations is good; Debian supports 58 languages now, and may support 77 by the Lenny release. The Smith Review Project has been working through the package base, ensuring that package descriptions are, well, descriptive, in proper English, and easily translatable.

On the ports side, the Sparc32 port has been officially retired; to the dismay of relatively few users. The Lenny release will include a new port: Debian GNU/kFreeBSD, which is based on the FreeBSD kernel. Martin thought this port would appeal to those Debian users who have been complaining about the increasing "multimedia orientation" of the Linux-based distribution.

Much work is going into making the package repository more searchable. The debtags project, which is putting a set of standardized tags onto packages, is relatively advanced. This effort will address a number of longstanding problems, like the fact that a search for "image editor" does not turn up GIMP, which is an "image manipulation program." Debtags will also make it possible to search for packages which are related to other packages. There is also the apt-xapian-index project, which is working toward indexing all package metadata and providing a fast search capability.

Other bits of current status:

• The debian-med project - building a version of Debian aimed at the medical industry - is headed toward a 1.0 release.

• The Debian mirror network is growing. There are six new primary mirrors, and around 100 new secondary mirrors.

• Lenny will use UTF-8 nearly exclusively. Developers are working on fixing the remaining packages which do not yet support UTF-8.

• The venerable dselect is almost retired. There are still dselect users out there; Martin suggests that all of those folks move to aptitude.

• There are a lot of new games coming into the distribution.

• The Etch-and-a-half release will be happening soon. This is a version of Etch which offers a 2.6.24 kernel - needed to make Etch work on newer hardware. The original 2.6.18 kernel will remain an option for Etch users.

Looking forward to 2008, Martin noted that the Lenny release is currently planned for December. Lots of emphasis on "planned" - given Debian's history in this regard, few people actually expect the release to happen on time. Martin did say that things have been getting better in this regard, with Etch being "only" four months behind schedule. A Lenny release which is only a couple months late seems feasible.

Something which is just coming into play is the new "Debian maintainer" status. Unlike full developers, maintainers cannot vote, have no access to the debian-private list, and do not have much access to the wider Debian infrastructure. About all they really can do is upload a specific set of packages. So the "maintainer" designation is good for those who want to maintain a small set of packages, but who are not looking to be an active participant in Debian as a whole, and who do not want to run the "new maintainer" gauntlet.

Martin was asked whether there was any thought of downgrading any existing developers to maintainers. He said that there was some interest in doing that. There are currently just over 1000 developers, all of whom have full access to the repository. Some 400 of those are inactive, but they still possess a key which lets them make changes to the system; this is a clear security issue. The MIA project is looking to identify these people and, eventually, move them to inactive status. On the issue of whether the project would be forcibly downgrading active developers who, for whatever reason, are not entirely welcome in the community, Martin says that will not be happening. There is just no way to do it without bringing massive disruption and flame wars, and nobody wants that.

There was also a question on the role of the debian-private list. The biggest use of debian-private, according to Martin, is vacation announcements; developers need to let the project know that they will not be around, but they do not wish to announce their absence to the wider world. There are some other discussions there too, of course. Current policy says that debian-private discussions will be disclosed after three years in the absence of a request to the contrary. There's an effort afoot to disclose older traffic from before the adoption of that policy, but that requires the assent of all of the participants.

The debian-women project, unfortunately, is currently stalled; the main participants have not had the time to push things forward. The #debian-women channel remains active, though, and is generally a nice and supportive place to be. There are currently about twelve active female contributors to Debian. Martin thinks that women are becoming more present in general, though, and he stated that "the Debian cowboy days are done."

On the packaging front: the packages.qa.debian.org site has been redone in "beautiful CSS." There are now RSS feeds for those who want to follow the status of specific packages. A new "LowThresholdNMU" flag has been added; this is essentially a statement on the part of the maintainer that he will not get offended if others upload fixes to the package. Packages can now use bzip2 compression. There has also been a major rework of the shared library infrastructure, which now looks at actual symbol use when determining shared library dependencies. This change should make it possible to install individual packages from testing into a stable system without having to update all of the libraries that package uses.

There is a growing trend toward team maintenance, especially for the larger package sets. This approach increases the robustness of the system and minimizes problems with MIA maintainers.

Version control systems are working their way into the Debian infrastructure. Packages can now have a set of Vcs-* headers which point to the upstream source repository; these can be used, for example, with the debcheckout command to clone the source repository without having to know anything about the source management system used. Version control systems also offer a solution to the current problem of "hackish packaging tools" being used by many developers. In the future, source packages might just include a shallow repository which can be fed straight to git (or some other system). This project is stalled at the moment, but Martin thinks it will go somewhere; it would be nice if the distributors could come up with a common scheme that they can all use.

The final topic in this session was a question from the audience on whether Debian might ever go to a shorter release cycle. The projected 18 months for Lenny seems like a step in that direction, but 18 months is still quite a bit longer than the cycles used by many other free distributions. Martin thinks that going shorter is unlikely. The fact of the matter is that distribution upgrades are a hassle, requiring a fair amount of administrative attention. Ubuntu may have made some progress with its use of upgrade scripts, but the basic problem remains. On top of that, shorter release cycles would necessarily lead to a shortening of the time for which security updates are available for any specific release. And that, in turn, would force users into more frequent updates whether they want to do that or not. So one should not expect six-month release cycles from Debian anytime soon.

---

(Log in to post comments)

> On the packaging front: the packages.qa.debian.org site has been redone 
> in "beautiful CSS."


Wow! Let me be the first to say I *love* the new design. So fresh and bold, yet with echoes of
the venerable old system.

I'm glad that they let you choose the old design with a cookie. I know a lot of people won't
be able to get used to the new one, so good that they have the option. I'm sure without it
they never would have managed to get the consensus together to make such sweeping changes.

I agree, it is a really breathtaking design. I especially love how it is completely identical
to the legacy design.

One point of worry for me is that the layout is too advanced. The CSS is _huge_ (7 entire
lines!) meaning that scrolling the page could slow down to a crawl on older computers. Perhaps
a more lightweight design should be the default?

Well, I don't know about anyone else, but I tried both Iceweasel and Konquerer and never
noticed a change to the page at all regardless of the setting and whether I clicked the
Remember This Style button or not.

I guess my Sid installation is CSS incapable.  :-\

"...port may be of interest to those Debian users who have been increasingly unhappy with the 
"multimedia-oriented" nature of Linux-based systems"

What is "multimedia-oriented nature" supposed to mean? The project page too doesn't explain 
anything about it. Anyone knows what's the idea behind this port - it sure seems like
significant 
effort and there ought to be reasons better than just for the heck of it?

Ha.  Sounds like a codec argument in disguise, but this isn't a license change -- it's still
GNU software, on free Debian, just with a BSD kernel.

Next question -- where did you find that statement?  It'd be nice to have a referent to what
you're commenting on, unless it's from the lost half of the text.

It was right there in this article text when I commented - no longer there. Not sure what
happened.

the 'increasing multimedia orientation' is a thing the distros are doing, not the kernel. the
kernel folks are working to solve any problems that the kernel has that cause grief with
multimedia use, but usually these impovements help other workloads as well.

putting the same multi-media oriented userspace on top of a different kernel won't help unless
the new kernel is a better fit for multimedia uses, and I haven't heard that the *bsd kernels
are multimedia powerhouses.

I suppose I should not have made this comment as a representative of the Debian project, and I
probably did unjust to the Linux kernel in whole. This is entirely a personal issue, I have a
number of problems with Linux memory management, scheduling, and some other points relevant to
production use. I've had some of these problems for years, but they seem never to get fixed,
while development is fast-paced. Then I look at some of the work being done and I wonder what
the priorities are.

Regardless, I should not have made this comment and I apologise for it.

Don't worry so much about the thought police. :)

Just explain that you don't want people to misunderstand you. It's a natural side effect of a
human language that these things happen.

I don't. But since the statement I made is not important to me, it's best to just retract it.

Simple. ZFS. It's in FreeBSD kernel. Now Debian has only to borrow apt-clone from Nexenta to
be dream OS.

Mr Corbet,

"....have no access to"

Missing text ?

<snark>
If the LWN source was available, other people could help try to find this bug.
</snark>

British English too. Like `whom', it's at that `last stand of the dying 
feature' stage, being seen as pretentious and overly formal.

Hah, and then there's the passive tense (where I'm not tense because I say 
things in a really non-aggressive manner, you know.)

;}}}}

(sorry, I've lost my active voice, I have a cold)

dselect almost retired? Isn't that going to annoy certain past project leaders who also happen
to be dselect authors?

*paging Ian Jackson*

;}

dselect got several patches lately and is still in maintenance in the dpkg git archive. it no
longer belongs to base, so will not be automatically thrown in to any new install.

Thanks, Jonathan, for a good article.

I have to make one correction: I mentioned that there was virtually no security support during
the "etch" release. Thanks to Moritz Mühlenhoff, who 
spotted my error: that should have been "sarge". The problems with security 
support had long been resolved by the time "etch" was being prepared, and this was in (large?)
part thanks to Moritz. Sorry for the screwup!

-m

Last I heard there were licencing issues (the CDDL/GPL incompatibility).

All of this is paraphrased, and if I remember correctly, it's been a while.

Basically, Nexenta and some (bigger) parts of Debian disagree on the GPL's operation system
exception clause.  

As the CDDL license is incompatible with the GPL, the only way forward appears to be claiming
the Solaris libc is part ot the operating system and therefore no problem.  However, GPLv2
says that those system libraries must not be distributed along with the GPL source in that
case, which would be the case if you stick everything on a CD.

GPLv3 appears to clear that up, and there are rumours that Eben Moglen and the rest of the FSF
believes the GPLv2 operating system exception is meant to be the same as GPLv3's, but I
believe no official legal advise has been given on this issue yet.  Any such pointers would be
welcome.

I'm sorry, I don't exactly follow your argument.  Let me put it this way: what are we afraid
of?  Are we afraid that if we start happily using Nexenta -- a Free, Open Source kernel, Free,
Open Source libc and libraries, and a complete Free, Open Source userland, that this will
somehow lead to Microsoft taking over Firefox?

I am not trying to be provocative here, but I just don't understand why fear, uncertainty, and
doubt about some subtle hypothetical issue is important enough to cause people to avoid using
and contributing to a beautiful, Free, Open Source set of tools.

As I understand it, the designers of the GPL v2 did not intend for the GPL to cause this sort
of incompatibility, and they did not think that the GPL v2 did cause such incompatibility, but
since some people were apparently afraid that GPL v2 might do so, they further clarified GPL
v3 in order to assuage people's concerns.

Regards,

Zooko

the CDDL is not compatible with the GPL period.

this means that you can't take CDDL code (ZFS) and include it in GPL code (the linux kernel)

until sun changes the licensing of ZFS to be compatible with the GPL there is no way to
integrate the two.

there are portions of ZFS that have been released under the GPL (enough for GRUB to be able to
read files from it), but most of the code has not been.

the only people who can fix this incompatibility are at Sun.

I wasn't talking about shipping a kernel comprising Linux and ZFS.  I was talking about
Nexenta -- http://nexenta.org -- a project to compile Ubuntu packages on Solaris so that you
can use all the familiar userland tools such as apt-get and also the beautiful new Solaris
tools such as ZFS and dtrace.

For example, the nexenta folks have created a tool called "apt-clone", which uses ZFS
snapshots to make it possible to rewind to that particular set of installed debian packages.
Isn't that awesome?

Another rumor:

Matt Lee from GNU claimed that GLPv3 is being considered for OpenSolaris.

http://linux4coffee.wordpress.com/2007/10/14/the-gnu-hurd...

I mailed him for a clarification and he said he had been speaking to "very senior people" at
Sun who were "considering it very seriously". Haven't heard anything recently though.

When did a 6 month release cycle become desirable? New hardwarre support is nice, but even the
quick release folks  at Ubuntu do 18? month LTS versions.

Truth in advertising, I do run Debian testing on workstations, now.

Good work Debian!

It is my experience that the LTS releases are mostly used by server people, whereas desktop
users are usually more in a hurry to get their new hardware supported. It's a basic conflict
of interest, the server people want long release cycles, the desktop people want short ones.
Debian aims to be an operating system for everyone and is therefore caught in the middle.

Plus it's nice when systems syncronize.  Gnome and X both have a six-eight month release cycle
and so do lots of other big software projects. 

Application developers depend on Gnome's new stuff to get the latest and greatest features.
Gnome depends on features being present in X to get the newer features (like compositing or
xrandr improvements). X depends on the kernel for some of it's features (like DRM texture
management improvements for compositing and hotplug input devices support).

So by having everything sync up it makes Linux more reliable platform for software developers
since they can depend on release timelines. Projects have realistic expectations on new
features and users get the best improvements, better hardware support, and quicker bug fixes.
So on and so forth.

Another example is Gstreamer. With no time line for releases projects based on Gstreamer were
very hard for users to test and use since no distro had the up-to-date dependancies for the
software.  In order to get some of the neater gstreamer-based applications working users and
testers would end up having to break dozens of other programs by compiling custom versions of
gstreamer.

With Debian, for previous releases, people were very hurt because they wanted to use Debian as
a platform for their own projects. As months and years went by before another stable release
those projects died on the vine.

Six months is a good target to aim for. If you overshoot it then you'll get a new release in
eight months. As it works out (with holidays and such) you end up getting a rotating schedual
of 2 releases at the beginning and end of one year, and summer of the next. That's pretty good
and will help keep Linux very competative with Vista or OS X.

Another solution is just running testing on your desktop.

The fourth issue of the "misc development news"
(http://lists.debian.org/debian-devel-announce/2008/02/msg...) mentions a few other
topics which I forgot, such as the Debian Enhancement Proposals.

That archive page looks very badly smashed...