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.
I have found linux bliss in debian I just wish someone would release a CD a little sooner with some of the more recent packages like an updated version of some more of the packages. I have slink 2.1 r 3 but sometimes it is a little difficult to get the packages from the net.
Slashdot social engineering at it's finest
sorry, couldn't resist :)
How does one pronounce Debian and what does this word mean?
The project name is pronounced Deb'-ian, with a short e, and emphasis on the first syllable. This word is a contraction of the names of Debra and Ian Murdock, who founded the project. (Dictionaries seem to offer some ambiguity in the pronunciation of Ian (!), but Ian prefers ee'-an.)
As a RedHat-only person for a while, I've recently begun using Debian. It's GREAT.
:) For the most part, "unstable" right now means "sometimes dependencies might be wrong, oops". I've never gotten a broken package, or had any trouble using potato rather than slink.
Basically, you give it a pool of FTP sites, from which you want to choose packages. When you want to install a package, you tell it. If there are any dependent packages not installed, it asks your permission, then installs them. As packages are installed, it asks you questions so that they'll be configured and ready-to-run.
I use the unstable tree, and it's not
apt is indeed incredibly powerful. I, for one, think that console-apt is DONE. It does everything I need it to, AT THE CONSOLE, with what is (to me) a great interface.
WMBC freeform/independent online radio.
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.
This is the exact reason why a Redhat is needed. Now that they have the market capitalization they don't need to wait until someone wants to work on a particular project. They have talented people on the payroll that they can assign to work on needed technology. The Open Source attitude has been very successful to date, particularly because of the attitude expressed by Wichert that solutions arise from need and interest, but to grow Linux so that it can truly compete with MS and others, it needs to support technologies quickly. No more of this USB in the 2.3 kernel stuff or Firewire being supported who knows when. Linux needs to take off its training wheels and go play with the big boys. Adopting a big business attitude that can coexist peacefully with its Open Source origins will get it there and is Linux's greatest challenge.
Hates people who have stupid little sigs
uh-oh, the `pile anything on top of each other approach' to package
management is coming to the BSD world.
On reflection I think it is a good idea: getting Debian to work of
top of FreeBSD is a good test of the Linux compatibility mode. Its a
shame the Debian effort doesn't look very ambitious, but I guess its a
voluntary effort. A port of glibc would be a very good thing for
BSD...
One constantly hears conflicting opinions on pentium optimiaztion. Advocates say it will give you a performance hit on 486s and the like but you should see an improvement on any pentium class machine. Opponents frequently say it wont run at all on a 486 and you'll see no improvement or a hit on AMD or other p class chips. I'd like to see these benchmarks people keep mentioning.
As for Wichert's statement that it only really helps with certain programs, I'd like to say the ones it does help with seem to be important ones. I'm currently using a Dual PII box on which I have run both Debian and Stampede, and while I didnt sit around doing benchmarks all day, I did notice a very large difference in the performance of KDE. Even if pentium optimization only helps out with things like KDE I'd say it's worth it.
The apt library is really powerful and does everything you want it to do,
In fact, the poor and out of date libapt documentation aside, this isn't true. Among other things, libapt isn't good at:
-> keeping track of automatically performed selections and removals; each frontend has to do this itself
-> allowing in-progress downloads to be manipulated on a fine-grained level (ie, cancelling individual jobs)
-> keeping persistent state across program runs: knowing, for example, that the user specifically asked for a particular program to be held back at a lower version than the newest available.
Not that it isn't a wonderful tool, but it's not perfect -- not by a long shot.
Daniel
Shameless plug: I have a very early prototype of an alternative apt frontend at
aptitude.sourceforge.net
. Please download it and send me comments so I can fix problems in the next version!
Hurry up and jump on the individualist bandwagon!
First off, IANAL, but how about calling it the COSL (see subject) or just CPL (Commercial Public License. COSL is probably most accurate.
Now get reps from several companies (IBM, Sun, Troll, Redhat, etc.) that are interested in doing Open Source work and allow one Contract law lawyer each in a room with ESR, Bruce Perens, and the GPL lawyers. Let them hash out the items that they feel a company needs in order to release a product with the source code available! Don't make it mandatory that the license be used for every product, but if they want the Open Source seal of approval or whatever then the source MUST be available!
The software the license applies to could be shareware, demo, free (gratis), or regular off- the-shelf-pay-me-fifty-bucks software, but the source must be available as well as a method for submitting Bug reports publicly and public request for feature improvements/changes. I'm not saying the company would have to accept each and every bug fix to include in the next release, but they should consider them and use their programming standards to fix the problem in a reasonable amount of time. And test that it doesn't break something else. (Hello, Microsoft products.) My idea about feature changes/requests is that if the users have a hard time getting to or using a feature that is used all the time, then this would improve useablity. Kind of like Ergonomics, also if the company mistakenly moves a feature around in the menus from one release to the next without improving useablity I want to be able to let them know. (In IE 4.0 the internet options are in one place and in a different one in IE 5.0. Hello MS are you listening, didn't think so. They also change the name of features for no reason.) Basically I want the software companies to act differently than MS. Big surprise!
Now, make the license available on the net for peer review and later for use by any Commercial company that wants to do Open Source software. They can just place their companies name and the name of the software in a blank in the contract. Just like the generic standard mortgage contracts.
Well, that's my two cents, I'll crawl back in my cave now.
--Somewhere there is a village missing an idiot.
You mean like the %pre, %post, %preun and %postun scripts in RPM?
The person who posted this is the same guy that was interviewed. That's right! He's the featured man of the day.
It's FUNNY. Just mark the think up to 5 and leave it there. Right now the struggle between moderators is wasting a lot of points.
This article posted with my default of +2 in an effort to make it appear close to the FUNNY comment. Please leave it at +2 for that purpose.
Thanks
If tits were wings it'd be flying around.
In the earlier article my question was basicly "With Slink being out of date, and Potato having a flaky install, how does one do a fesh install of Debian now, and have all the recient packages (Xfree 3.3.5, 2.2.13, etc.)
/etc/apt/sources.list to unstable
Here's what I did, and thanks to the reply to my post that was helpful:
1) Installed Slink, with all the packages I wanted. (installed flawlessly, as it should)
2) Compiled my own kernel. I tried to do skip this step and alot of the Potato packages chocked because I wasn't running a 2.2.x kernel. SO I had to start over.
3) changed
4) apt-get update udates your package database to the latest version that are in unstable.
5) apt-get install dist-upgrade upgraded all my packages that I installed with Slink. Updated packages included XFree86 3.3.5, Enlightenment DR16.3, Latest GNOME, etc. It failed to to update a couple packages, but they weren't needed and I just apt-get remove
6) Went though the set-up process. Uncluding XF86Setup, untar'ing my old home directory, etc.
That's about it. I have a full Debian distro with later stuff then I even had with RedHat 6.1 Apt-get served me so far when I didn't have libgnome-dev(compiled a couple gnome aps). Unstead of looking for RPMS like I did with RH, I just typed apt-get install libgnome-dev and waited a few minutes and had then already installed and read to go.
Been running fine for 4 days now, and it's great.
I encurage anyone thinking about Debian to give it a try. My only gripe is that I didn't install it months ago =)
The point about the install-script has already been made in another post.
/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.. "
I'll object to the others:
"For example, rpm allows you to have multiple versions of a single package installed."
That's not entirely true: RPM will allow that by default (provided that there's no file conflict), and this can sometimes be useful if you wish to have multiple versions of a library on your system for backwards compatibility purposes.
However, the packager is given the choice to state a "conflicts" clause, which supports version information. So to emulate dpkg, packagers should simply assert that some version conflicts with all earlier versions, and the trick is done.
Now about the other one:
"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
Again, this is not entirely accurate: RPM allows a packager to specify a "Virtual capability": Simply put, a package foo can assert to provide a capability bar, and other packagers can express dependencies to the bar capability, rather than the libfoo file.
I'm not saying this to bash dpkg in favor of RPM, but just to set some facts straight.
For instance, I like dpkg's "recommended" dependencies (as opposed to RPM's only "hard" dependencies).
I think the two technologies are roughly equivalent, and that Wichert is oh-so-right in saying that in the end the choice boils down to personal tastes, familiarity and stability.