Re: An alternative to deb-make Re: deb-make
[Please don't cc: me---I do read the list]
Manoj Srivastava <srivasta@datasync.com> writes:
> I'm afraid I don't understand. What is broken in the standard
> about multi binary packages?
I guess that technically, I should have said that "the programs around
which the standard was written doesn't acknowledge that multi-binary
packages exist (and don't do some other things well---which
complicates developers lives and creates non-standard behaviors--and
suggests that the standard should be considered broken".
For instance:
1) Since the dpkg-whatever programs require that you dump all files
they might look at in a single /debian directory, you end up having to
give files non-standard names---names which, I've found in working on
the Alpha port, are not consistent.
* This wouldn't be necessary if dpkg-whatever used the filesystem as
a database for storing files associated with particular a binary
package in a unique place.
2) All the dpkg-whatever programs assume that you will be using
debian/tmp (since they only think in terms of a single binary package)
for everything, an obviously invalid premise for the "number of binary
packages you have" - 1. So you end up with directories with
non-standard names (again, inconsistent).
* This wouldn't be necessary if dpkg-whatever used the filesystem as
a database for storing files associated with a particular binary
package in a unique place.
3) Dpkg-shlibdeps and dpkg-gencontrol require that you remember and
use a number of flags dpkg-shlibs/dpkg-gencontrol/dpkg-??? in order to
have it work on multi-binary packages.
* This wouldn't be necessary if dpkg-whatever used the filesystem as
a database for locating files and directories associated with a
particular binary package so that it could run operations against all
packages and store the results in the right place.
All this despite the fact that the utilities in question already have
access to sufficient information to do these things---had they been
designed well.
If the "real" utilities took care of some of this (some of which would
require changes to the standard to implement, since the standard was
written with single-binary packages in mind), deb-std would never have
been written.
Oh, I'm sure someone would have come up with an auto-doc compressor or
some other small utility functions, but there wouldn't have been this
big utility that is trying to make up for shortcomings in the standard
and in the available tools.
And to address some other responses, no, it's not impossible to
maintain these packages under the standard---I've done it with several
packages. But, as I found out when I converted ncurses to the new
package format, it is much harder than it has to be, *because the
standard, and the programs that implement it, weren't designed with
this in mind*.
And since we have a more than healthy number of packages that are
multi-binary, and since many of those are essential, I state that I
think the standard is broken.
> The process seems simple enough that kernel-package *automates* the
> multi binary package kernel-source-X.XX (and headers, and
> image). Unless you call the kernel packages trivial ;-).
I wouldn't call kernel packages trivial, but from glancing at the
`dpkg --status` of my local kernel image, I notice that they probably
don't have to deal with certain programs like dpkg-shlibdeps, right?
Thus I think you haven't necessarily been subjected to some of the
more egregiously unthinking behavior of some of the programs.
> I don't think the standard is broken in this regard, and I
> didn't notice any contortions. Could you please elaborate?
Again, while the kernel stuff isn't trivial, I also suggest that it's
something of a special case.
Anyway, writing this little missive has actually convinced me that I
don't want a new utility---I want the dpkg-whatever programs rewritten
so that they display an appropriate amount of intelligence. If we do
that, the rest will probably become moot.
But feel free to ignore me---I don't care if everyone else has to work
harder. :). I've got my tool, I'm going to be shipping it with all my
packages, and _I_, at least, will be free of much drudgery.
Mike.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: