Re: Interesting dpkg issue, plus thoughts...

[Christoph Lameter <clameter@waterf.org>]

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

Debmake does not make decisions for you it just provides defaults.

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? 

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 often think dpkg would be a package satisfying the requirement
in the policy manual to be moved into contrib. Its orphaned.

Lets fix it or get rid of it.

On Fri, 11 Jul 1997, Dale Scheetz wrote:

>I don't mean to make this an argument against debmake (although I have a
>fundimental objection to this package) but I do feel compelled to point
>out that it was conceived as a method of removing the need to deal with
>the source package restrictions. The attempt to provide the maintainer
>with a tool that would make many packaging decissions automatically,
>although intended to make the maintainer's life easier, has actually
>created more general packaging problems of its own.

>The problem that it presents comes from the fact that debmake problems
>are preceived as dpkg problems because that's where they appear (during
>package creation). New package maintainers, encouraged to use debmake to
>"help" them build their packages, submit bug reports against dpkg when it
>doesn't work. The problem this creates comes from the fact that debmake
>becomes the "de facto" defining influence on dpkg. Many of the changes in
>dpkg that have been made, as a result, are to make it conform to the way
>debmake percieves the package system "aught" to work.
>
>Again, to try to make my point clear, I am asking that we change our
>attitude about "The Source Package Format". Work toward making packages
>that work within that defined structure, rather than trying to make the
>structure conform to our own personal vision of what the package system
>"aught" to be like. The number of packages that can't be re-built from
>their source constituents, using 'dpkg-source -b', appear to be
>increasing. We need a much more uniform application of the standard than
>what is currently in operation.

We need to fix dpkg-source so that it does not package a sourcecode
archive that cannot be unpacked later. This has been reported over and
over. FIX IT!

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---


--
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 .