Re: An alternative to deb-make Re: deb-make

[Galen Hazelwood <galenh@micron.net>]

Michael Alan Dorman wrote:
> 
> [Please don't cc: me---I do read the list]
> 

Not done.  (50 points to anybody who gets the reference.)

> 
> 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:
> 
[snip good points]
> 
> 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.
> 

Amen to this.  In fact, I'm so impressed by this conclusion (since it
happens to be the same one I reached :) that I'm going to stick my
neck out and make some concrete proposals right now.

1) dpkg-source should be loosened to allow creation of directories and
   files without problem.  It can still refuse to allow changes to
   binary files, as this error is usually the first clue that I
   forgot to clean up before trying to build the diffs...

2) The new "standard" for arranging the debian directory:  We keep
   things as they are for single-binary packages, but multi-binary
   packages now create a directories under debian for each binary.
   This is an easy way to remember which postinst goes with what.

3) Single-binary packages build in debian/tmp, and multi-binary
   packages build in debian/tmp-foo, debian/tmp-bar, etc.  By keeping
   this consistant between packages, we can make the behavior of other
   tools smarter.

4) dpkg-gencontrol be altered to reflect these changes; when called
   without arguments in a single binary package, its behavior should
   remain the same (build control file in debian/tmp/DEBIAN).  In multi-
   binary packages, it should generate control files for each binary in
   debian/tmp-[binaryname]/DEBIAN.  One call does it all.

5) dpkg-shlibdeps actually dosen't need changing, really...it's current
   behavior is probably correct.  I can't think of any "magical" way it
   can determine what binary any given executable belongs to, so -d
   should still be used.  Another possibility is creating different
   shlibdeps files in subdirectories of debian, with a new command line
   flag.  I don't see that as much of a gain, though.

Any comments?

--Galen


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