Slashdot Mirror
Interview: Debian Project Leader Tells All
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.
(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.
----------
Next week's interview: Curtis Chong, Director of Technology for the National Federation of the Blind, discusses computer and Internet disability issues.
sorry, couldn't resist :)