Re: Senseless Bickering and Overpoliticization (fwd)
Hi all,
I was sent this from a Debian Developer (and one of the Hurd
people). He didn't Cc any lists, so I'll remove his name. There are some
legitimate concerns here - at least with the impression that's given,
perhaps?
Matthew
---------- Forwarded message ----------
Date: Wed, 1 Sep 1999 21:53:12 +0200
To: Matthew Vernon <matthew@debian.org>
Subject: Re: Senseless Bickering and Overpoliticization
<MCV: snip>
it's nice of you to cover the asses of the dpkg developers, but John is
right. Look at the dpkg bug list, and you will notice one thing in a few
seconds: dpkg is not actively maintained.
The history of dpkg is along and complicated one, but it is a fact that dpkg
was long forgotten by all upstream authors (IanJ and Klee Dienes).
<MCV _I_ know this is inaccurate, but I don't think he does>
Of course, a lot of bug reports were fixed by NMU's, but that the NMU's were
not followed by an official release many months (I am tempted to say years
here) is disturbing. I know that IanJ "worked" on dpkg lately, he catched up
at least.
The maintenance however is not something to worry as there are always kind
people to work on it and make NMU's. At least to keep the boat swimming. The
lack of coding new features and rewriting chunks of the code is something to
worry.
Look for example at the build rules. The current (ab)use of the auto* suite
sucks. Doing it proper is not hard, though. Why was it never improved? (In
short: Why is it needed to run autoconf in the rules file).
Look for example at the performance: Even for simple database look ups dpkg
does read in the entire database.
<MCV - I'll have a look at this. I presume he means dpkg -s. Perhaps a
hash table or somesuch?>
Look for example at the dependencies to external programs: dpkg runs a lot
of external programs to do its job. If one of them breaks, you're in trouble
(tar comes into mind). That's not so good.
Look for example at the organization: One big binary, no modularization.
Makes it hard to extend it, really.
Look at the support for other architectures: For example, what does "dpkg
--print-architecture" really mean? Nobody could tell me, but it is one of
the most used options in rules files (my dpkg-architecture fixes this, the
mentioned option never had a well defined meaning and is obsolete).
Look at the shared libs handling: You need .shlibs file, probably
.shlibs.local file, and you need to maintain the files manually. RPM does
this automatically.
Look at the source format: One diff, no provision for multiple diffs (foir
example for different architectures). This makes it difficult to maintain
huge programs like X, egcs, gdb etc. All those maintainers needed to develop
individual solutions for multiple patches, which means multiplying efforts
and difficulties for people working on a package which is not their own (I
know what I speak of, I ported those packages to the Hurd, and needed to
learn several different ways to do this source patching).
No provision for source dependencies, making it difficult to bootstrap new
architectures.
Of course, dpkg does its current job quite well. It would be horrible if it
didn't. But it is a fact that the siuation could be much better. development
has stalled since a long time.
About dselect: All hope lost. It also does work for what it does, but it is
*not* something you can use intuitively. There is no hope for dselect to
outlive any other package installation system.
Reply to: