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.
Good.
> 1) dpkg-source should be loosened to allow creation of directories and
> files without problem.
Definitely.
> 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.
Yep.
> 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?
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: