comment on "User Review of Debian GNU/Linux"
Alexander, since I met you and answered some of your questions and
work with your brother, I felt I ought to just provide some of my
thoughts on your review, "A User Review of Debian GNU/Linux". I'll
just start with saying that my answers are colored by my experience of
being a Debian user since version 1.3, a Debian developer since 1998,
the install system documenter for Slink, and the maintainer for
Potato. Of course, Debian is a large project and others have other
expierences
I can relieve you right away by saying I agree with that I thought the
review was pretty balanced, I don't see anything in there that was
unfair. Some things maybe I think had too much stress placed on them.
A few comments along the lines of tech support. This probably points
to some additional documentation we could use:
| I ran into this problem when I tried the get the latest version of
| AirSnort to run on my system. I was having trouble running it, so I
| wanted to get the latest version of wireless-tools package. Apt-get
| only got me an older version from the stable repository, but I saw
| there was an up-to-date version in Debian unstable, so I downloaded
| the .deb file from the Debian web site. Trying to install that
| brought up the complaint that libc6 was out of date, so I grabbed an
| updated libc6 and crammed it in there. Needless to say this broke
| quite a lot, and my old friend apt-get was of little help in this
| situation since it could only pull from a large database of programs
| that relied on the original libc6, and the default settings are such
| that broken packages aren't automatically downgraded.
Yes. I would suggest that the way you should have gone about doing
this was by having this in /etc/apt/sources.list:
deb http://http.us.debian.org/debian stable main contrib non-free
deb http://http.us.debian.org/debian unstable main contrib non-free
And this in /etc/apt/preferences:
Package: *
Pin: release a=stable,o=Debian
Pin-Priority: 850
Package: *
Pin: release a=unstable,o=Debian
Pin-Priority: 100
This not-so-well-documented feature will make 'apt-get install foo'
get foo from stable, but 'apt-get install foo/unstable' get foo from
unstable. You might have to do 'apt-get install foo/unstatble
dependency/unstable' as well. There might even be better ways to do
it, this is just how I do it.
| This is the biggest problem when Debian sources become too out of
| date - regardless of how technically brilliant Debian's package
| system is, it won't do much good if you have to circumvent it to
| install the latest software.
Well, as a volunteer organization, we set our own priorities. Each
developer is different, but generally, we don't upload new upstream
versions (even so-called bug-fix releases) unless we can satisfy
ourselves that they are as good or better than the previous version.
Packages like mozilla and xfree86-server and such are very large and
very complex and often involved significant packaging rework before
they are ready.
| Compounding this problem is that Woody will never officially get
| significant upgrades of ANY of its packages, unless they're found to
| have memory leaks or major security flaws. That means that Woody will
| never officially see a version of Mozilla newer than 1.0, or any
| version of OpenOffice.org. This system seems to sometimes run against
| the actual software projects by ignoring the fixes they make, in
| favor of the original code the developers themselves sometimes regard
| as broken. What's surprising is that Debian doesn't even update to
| the bug fix releases like Mozilla 1.0.
Well, I don't find it suprising at all. It's true, we basically do
release stable and forget about it (well, team security still worries
about it, and the stable install system maintainers, and often kernel
packagers...). Why is that?
Well, you already noticed that sometimes maintainers have a hard time
keeping up with new upstream versions. You're asking that they not
only do that but also test and build updates of software to deploy on
stable? That just isn't practical. No one would really do it, at
least, not consistently. It would require that each such developer
has one box (or chroot, or user-mode-linux, whatever) running
'unstable' and another with 'stable'.
We do have a policy, in fact, of now new upstream versions go into
stable after it's released. Even security or bug-fix releases need to
be back-ported to the version in stable, except for some exceptions
(kernels and the install system). But this is just a recognition of
the fact that no (or, at least, very few) Debian developers actively
target stable. We have our hands full just fixing the bugs, working
with upstream maintainers, packaging the new upstream versions, etc.
| The awful truth is that if you want to run the latest software, or
| anything close to it, currently you have two choices on Debian: run
| Woody and use the wealth of unofficial backports or run unstable and
| churn through the frequent changes. This means that currently,
| there's next to no incentive to run Sarge, which will ultimately
| become the next release, since it's the worst of both worlds, old
| software, incompatible in some instances with the backports.
|
| This will likely change in time as newer packages make their ways into
| Sarge, but right now that's the case. While I thought this was due to
| Debian's being overly diligent with security and stability, it was
| pointed out to me that there is an issue with the glibc (the one I
| hosed earlier in this review) due to Sun's contract that conflicts
| with Debian's software guidelines and developers are trying to work
| this out.
Both of your explanations for the lag in testing are wrong, actually.
The Sun license thing has been revealed as a Red Herring sadly
propogated pretty widely by Debian Planet. In fact, the licensing
issues go back very far, even before stable release, so that wouldn't
hold up glibc.
The real reason is that we're making a major ABI change, similar to
the transition to glibc6 or from a.out to ELF format. This takes a lot
of time to get right. I think it's nearing stablity, but I don't
follow this very closely.
I feel like you put an awful lot of stress on the current lag in
testing, and it doesn't really feel all that fair. The wider
perspective is that we put the whole concept of archive "pools", which
the infrastructure which enables the whole "testing" distribution,
just over 2 years ago (Dec, 2000 to be exact). Woody is the first
release where "testing" became "frozen" and then "stable". Right now
we're experiencing a pretty large desync between testing and unstable,
but, as I said, it's to be expected considering the circumstances, and
it's also just a transient condition.
In summary, to me, Debian, as the largest and I think most dynamic
free software group in the world, is on some level an ongoing story of
scaling issues and infrastructure. Debian generally increase 50% in
size with every release (every 2 to 3 years, generally).
Infrastructure is added or improved when the inability to scale up
Debian with its current infrastructure becomes acute. You could also
use this perspecttive to look at the evolution of Debian Policy and
subpolicies (and the tightness of getting things into the core
policy), the Debian Constitution, the New Maintainer apparatus (still
needing improvement, I understand), the voting system, etc., etc.
I don't mean to pooh pooh Debian's #1 complaint (old versions of
packages) and the #2 complaint (the install system). As for #2, the
install system, now in alpha, has been rewritten from the ground up to
be modular, maintainable, and user-friendly. It might take a while
for it to quite get there, of course.
As for #1, package versions, in a way that really boils down to
shortening the release cycles, that I think is probably the hardest
problem in Debian to solve. I think the package pool system is a vast
improvement in the scalability of the Debian archive maintenance
itself, but at least in Woody, it didn't seem to solve the problem of
very long freeze periods. There's a whole cluster of problems that
we're going to have to keep working on, including release-critical bug
turn-around and the interdependancies between the install system, the
base system, kernels and other critical packages which are required to
have a functioning, installable, consistent release.
Our goal, ultimately, is the ability to do releases annually or even
semi-annually. Until then, our solution for the version problem is to
run stable and pull from testing or, if you're daring, pull from
unstable.
In the future, if you're doing a review, I'd be happy to proof a
document for things that could be improved or things that I think
aren't quite right.
--
...Adam Di Carlo...<adam@onshored.com>.......<URL:http://www.onshored.com/>
Reply to: