Re: Interesting dpkg issue, plus thoughts...

[Dale Scheetz <dwarf@polaris.net>]

On Fri, 11 Jul 1997, Christoph Lameter wrote:

> I am not aware of any changes made in dpkg for debmake. Given Ian's
> attitude towards debmake that is not to be expected.

Ian is no longer the package maintainer.

> 
> Debmake does not make decisions for you it just provides defaults.
> 
Debmake inserts a call to an outside script called debstd which makes
decisions at package build time about which files go where and in what
state while building the debian/tmp directories. Debmake inserts
additional files into the debian directory to hold distributed information
that would be better centralized in the rules file.
If debmake created a rules file with explicit sections for each phase of
the package construction I would have far less of a problem with the
concept.

> Maybe all of us in Southern CA should all get back to stick shift. It
> allows so much more control. Sometimes I have wished for a stick shift but
> you can barely get any cars like that around Los Angeles. Anyways debmake
> allows you to switch back to stick shift and can remove itself completely
> out of the picture. So please stop ideologizing. If you have something
> better then please out with it. Debmake clearly has its drawbacks. But as
> long as there is no active development going on with dpkg more and more
> problems will crop up. Faithful confessions of loyality to dpkg and
> against attempts to make things better do not bring us ahead. Where is the
> dpkg development team? 
> 
Where have you been? It's called the Deity team. The current dpkg source
is being maintained by Klee D. and given the volume of problems he has
been presented with, he has done a remarkable job. But because of the
pressures for change the current version of dpkg is pretty unusable. My
experience is that version 1.4.0.8 will work fine with a properly
constructed source package, and correct support software.

> There are not only bugs like you mentioned filed against dpkg but also
> fundamental issues like dependencies on virtual packages. Refusal to
> unpack a sourcecode archive that was packed without complaint and the
> like. Certainly those bug reports have to be weeded out that are
> unrelated to dpkg. But the claim that they are conditioned by debmake is
> ludicrous.

I certainly never claimed this. I agree that there are problems with the
current implimentation of the packaging software. One would have to be a
complete idiot to believe that. I am certainly capable of being an idiot,
but I don't think that is the case here.

> 
> I often think dpkg would be a package satisfying the requirement
> in the policy manual to be moved into contrib. Its orphaned.
> 
You do tend to read things in a way that suites your argument. I see no
indication that the dpkg package has been abandoned.

> Lets fix it or get rid of it.
> 
I would rather see your attitude repaired, if by fix it, you mean,
re-design it to suit your ideas of what a package system aught to contain.

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .