[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Galen Hazelwood <galenh@micron.net> writes:
> 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.


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

Well, I prefer debian/tmp/foo debian/tmp/bar debian/tmp/bar1, just
because that means that cleanup consists only of rm -rf debian/tmp,
which means any makefile we ship can be that much more general.

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

What would be more of a gain, though, is if dpkg-shlibdeps
automatically scanned the various tmp/package directories for the
executables, and created the different shlibdeps files---if
dpkg-gencontrol is going to be that smart, why should dpkg-shlibdeps?


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: