There are over 500 Debian maintainers today, up from 100 only a few years
ago. Wichert Akkerman has been Project Leader for this brilliant, sometimes
unruly (but always interesting) gang since February. Monday you posted questions for
Wichert. Today you get answers. (Lots more below)
1) Packaging Front End
by Christopher B. Brown
Considerable improvements have gone into the "back end," apt-get; while there has
been some experimentation with gnome-apt and console-apt, there doesn't seem to yet
be anything that unambiguously improves on dselect in terms of functionality.
With the things that have been learned from those attempts, is there likely to be some
sort of dselect-ng?
Wichert:
I really hope so. The reason that we don't have a super-glitchy-totally-awesome apt
frontend at the moment is that we have nobody who is willing and able to invest the time and
effort into making it. Unlike a commercial distribution, we can't just say `oh, this would be
cool. You there! Write this for us and we'll give you some money.' Somebody has to decide
for himself that it is an interesting project and make it. We can only encourage people to do
something and be very thankful when they do. At this moment the only interactive frontends
(that I know off) are dselect, gnome-apt, console-apt, Corel Update (formerly/also called
get_it) and aptitude. I would like to ab^H^Huse this opportunity to invite people to write a
good frontend or finish console-apt. The apt library is really powerful and does everything
you want it to do, the only thing missing is the frontend...
2) When will KDE be included in Debian?
by grrussel
Now that Qt 2 is free software, under the QPL, will Debian include KDE 2 when it is
released, based on Qt 2?
Wichert:
Short answer: yes. Long answer: we will include it when we're sure that all license issues
have been resolved. The QPL is a major step forward over the previous license and allows
you to use it in Free Software projects. There is still a slight problem though: it is not
compatible with the GPL. This doesn't mean that it's not free, but it does mean that if you
want to use code that has been licensed with the GPL and use it with something that is
licensed under the QPL (like Qt) you have a problem. There are two ways to fix that:
change the license for the GPL'ed part to add a special clause stating it is okay to do this, or
replace the GPL'ed part with something under a different license. KDE has stated that they
are indeed going to make or request the necessary license changes so all these problems
should be fixed for KDE
Once that has been done there is nothing to stop us from including KDE in Debian. Right
now we are mostly waiting for the KDE team to release the first beta of KDE 2 so we
actually have something to study and package.
More from grrussel
Also, do you feel it is better to keep Linux entirely DSFG free software only, or to
include software in some way restricted, such as Pine, Qt 1.x and Netscape?
Wichert:
I'm not so worried about having non-free applications for Linux. What does worry me is the
explosion of different licenses. Everything used to be relatively simple when almost
everything was either GPL, LGPL, BSD or MIT-licensed. But now we have the MPL,
QPL, SCSL, APSL, Artistic, Wine and other licenses as well. It seems that every time
someone starts a big project they want to have their own license. The result is more licenses
that conflict with each other in various subtle ways. A lot of the licenses are based on the
same principles, which suggests that it would be possible to replace them with a common
one. I would love to see an effort in which people from various backgrounds would try to
design a couple of good licenses which are acceptable by both the existing Free Software
community and the commercial world.
3) Choose HURD over Linux?
by sanderb
Since you are working on both Linux (established) and the HURD (experimental),
could you please tell what the advantages of using the HURD over Linux would be,
once the HURD would near completion?
Wichert:
The HURD is a very different thing from Linux, and we will have to see what the advantages
will be. Unlike Linux, the HURD is a micro-kernel based system. (Remember the flamewars
between Linus Torvalds and Andre Tanenbaum?) This means that unlike Linux you don't
have one big kernel, but a lot of very small objects working together. This gives you a very
flexible system where various parts are easily replaced. Right now most of the effort is being
put into stabilizing the systems and building the set of objects that will offer you a Linux-like
interface to the system. Once that has been done we will probably see more interesting
developments where non-Unix-like elements are being combined with the other interfaces to
produce.
4) RPM vs. dpkg
by Tet
What are your feelings on RPM vs. dpkg? Would it be better for Debian to add any
missing functionality to RPM, and then switch to that?
Wichert:
That's not really possible. The differences between rpm and dpkg are bigger then just the
format in which packages are stored; the interesting differences are in the way relations
between packages are declared and how the details of package installation and removal are
done. For example, rpm allows you to have multiple versions of a single package installed.
dpkg does not allow you to do that; it demands that you change the name of the package.
This might seem unlogical, but the result is that we can always be sure exactly what is
installed and not have to worry about exactly which versions of a package are installed, and
it allows us to upgrade and maintain multiple versions of a library in parallel. Another really
big differences is the way package installation is done: with Debian packages there are
separate scripts that are run before and after package installation and removal. Using those
we can do all kinds of special-case upgrades, handle error-recovery in failed and aborted
upgrades, etc.
More from Tet
In what way might Debian users benefit from sticking with dpkg over a modified RPM
with equivalent functionality?
Wichert:
It's indeed possible to modify rpm, dpkg or create a new tool to handle both formats. Once
that has been done the reason to stick to one single tool will mostly depend on what you are
used to, which one is the most stable, etc.
More from Tet
From personal experience, the thing that really stood out in Debian was dselect, but
that could sit on top of RPM just as well as it does on dpkg. Presumably the same
applies to apt (although I haven't looked at Debian recently enough to know about
apt).
Wichert:
Apt was actually designed to be reasonably independent of package format. It's indeed
possible to modify it to use rpm-packages. One problem with rpm-packages is that it is
harder to satisfy dependency due to the concept of file-dependencies. Instead of being able
to say `I need package b to be able to use package a' it can become `I need file
/usr/lib/libfoo.so.3.14 to be able to use package a' and then you'll have to find some way to
scan all packages to see which ones include that file, and then you're not even sure if they
have the right version of that file..
5) Slow release cycle
by Stephen
To my mind, the main problem that Debian has to sort out is its release cycle. It's one
thing to have a well-tested distribution by the time it's released, but it's going too far
to have packages a year or more out of date still in the current release. What steps are
being taken to address this? Or is there an expectation that everyone is happy to use
unstable?
Wichert:
The slow release cycle is indeed something we don't like and would like to change. There
have been plenty of discussions on possible new approaches, and good proposals have
been made. Unfortunately, changing the release process is difficult.
The most popular idea is a new approach we call package pools. Instead of dividing all
available packages into distributions like we do now, we put them in a single big pool. Then
we create a database with information about all available packages and use that for
distributions.
A distribution will then be nothing more then a Packages-file which lists the packages in the
distribution. This means that we don't need to do things like move packages physically from
one distribution to another or maintain a forest of symlinks; all that is necessary is to create a
new Packages-file. This makes it possible to create more distributions and play with new
release systems.
The only thing we would need to do is determine how the list of packages for a distribution
is selected. We could use it to keep stable and unstable distributions like we have now, but
we can also create new distributions such as a reasonably-stable or even things like
stable-with-new-X or stable-with-new-kernel, etc. Basically it gives us a lot of possiblities to
create and manage distributions, which should result in shorter and more regular release
cycles.
Implementing this will take time, and we want to do something for the near future as well.
What we plan to do for potato once it is released is create update-packs on a regular basis.
An update-pack is a set of packages that you can install on top of stable and extend or
upgrade it in some way. Examples could be a Y2K pack, a GNOME pack or a KDE pack.
6) Debian GNU/FreeBSD
by ajs
I was looking over the info on the attempt to integrate FreeBSD's kernel, and was
shocked to find that the people doing it were using BSD libc! Since glibc was designed
with a certain amount of portability in mind, why not port glibc to FreeBSD's kernel?
This would seem to be to make the overall port MUCH easier, as the rest of the
Debian code should be far simpler to port to a different kernel platform, but the same
libc...
Wichert:
The current idea seems to be to build a small system with the FreeBSD kernel and system
utilities, and use the Linux compatibility support to run the already existing Linux userland.
With this approach you don't have to work on most of the packages at all, which makes
things a lot simpler. The effort is still in the beginning stages though, so things might change at
some point.
7) Debian bureaucracy
by Big Dave Diode
I've been using Debian for a long time now, and I'd like to contribute back to the
project. However, I've been put off by what looks to me like excessive bureaucracy
and some infighting among Debian developers. Are there any plans to streamline the
process to become a developer/maintainer, and the developer contribution process
itself? What about fostering a more civil peer review process?
Wichert:
I won't argue that Debian has no problems at all. We have rapidly grown (100 people in
1995, 200 in 1997, and 500 now) from a small group of people to a big project. That
growth has indeed forced us to establish some rules and set some guidelines. Where Debian
started out with a single mailing list we now have over 50 mailing lists, a couple of teams with
dedicated functions, a constitution, and policy guidelines.
This may sound excessive, but it's not as bad as it sounds. 99% of all decisions are
announced and discussed on lists such as Debian-devel and Debian-project, and everybody
is free to contribute to the discussion. Since all lists are public, you will also see people
arguing a lot, and emotions can get heated at times, but I wouldn't call that infighting.
The new-maintainer process will indeed be revised. We have a proposal for a new process
that will hopefully reduce the load for the new-maintainer team and also help new
maintainers. I hope that we'll start using that soon. When we do, we will announce it on the
Debian-announce list.
A lot of this is a learning process for everyone involved. How do you handle growing from a
small group where everbody knows each other to a large group where you only know a
couple of people? How do you assure that everybody is working together and no conflicts
arise? How do you handle managing the necessary resources? How do you handle relations
with companies? All very real issues, and we are learning at every of the road. A very
interesting road, I might add.
8) Debian and Pentiums
by MoNsTeR
Is the Debian project planning, at any point, to create a Pentium-optimized release?
Wichert:
No. Some people have stated an interest in recompiling Debian with Pentium optimization
(there are even some scripts to automate that). However we feel it doesn't make much sense
for a couple of reasons:
if you compile something with Pentium-optimization it will be faster on an Intel
Pentium, and (possibly much) slower all other chips (ie AMD chips, other versions of
Pentiums, etc) or simply not work at all (on 486s for example). This means that only a
small group of people will benefit.
it doesn't really help you: if you look at benchmarks you will see that only a relatively
small number of programs benefit from this. So you do a whole lot of extra work and
gain very little.
If you are that crazy for speed you probably want to look for either a faster system or
a different architecture. Debian has been released for the alpha,for example, which
gives you a fast 64-bit architecture. Or you can try powerpc or ultrasparc.
9) Debian lite
(also by MoNsTeR)
Is the Debian project planning, at any point, to create something like a Debian-lite,
that includes only a core of packages such as commonly used libraries, X, popular
user agents such as mutt, lftp, and lynx, essential and popular server daemons like
sendmail, yp[stuff], nfs, and apache...? Basically, a distro of similar size to the more
popular distros that fit easily onto one CD.
Wichert:
Yes. This closely ties in with the archive changes I mentioned earlier: with the current system
it is hard to create a subset of the distribution since you will essentialy have to create a tree
of symlinks into the full distribution, and managing all those symlinks is a difficult problem.
Using the package pools all we would need to do is create a set of guidelines for what
should be in Debian-lite and the system will build it automatically.
10) Core
by Anonymous Coward
What do you feel about Corel Linux, Stormix, and other Debian-based distributions?
Do you think Debian may eventually form a common core or base OS that others
build distributions on top of?
Wichert:
I'm quite happy with all the Debian-based distributions. For both sides it is an unusual
situation: the people basing their system on Debian can start off with a complete distribution
and they don't have to worry about maintaining that, and can focus and their specific goals.
Most of the derivates also release all their changes, which means we get a lot of bugfixes and
new things such as graphical installers, management tools, etc. We can use those to improve
Debian again, and the cycle is round.
You could call Debian the common core on which Corel Linux, Stormix and others are
based in much the same way Red Hat is the common core of Mandrake and others. Some
people have mentioned it might be a good idea to use the Debian base-system as a common
core for the LSB. Since Debian is a community effort this does make some sense since it
means nobody will have complete control of it. If that is the best approach, or if others (or
even the LSB) will accept such a situation is something I'm not sure of. We will have to see
what happens.
slashdot.org |
