On Mon, Apr 26, 1999 at 10:06:57PM -0700, Joey Hess wrote: > It's become clear over the past half year or so that some of the historical > baggage debhelper inherited from debstd is holding it back. So I'd like to > start revamping debhelper and getting rid of these historical > inconsitencies, to make debhelper programs as clean and as easy to learn as > possible. Cool. > But now that we have a large base of packages that depend on the current > debhelper behavior, I have to make sure that those packages continue to > build with any changes I make to debhelper. Hmm, while I am playing with asclassic over the next few days I amy have thoughts on new functions or functions that could be nicer. I'll offer them as I come up with them. > I think I have a solution - starting with debhelper version 2, debhelper > will continue to behave as it does now by default. If a special environement > variable, DH_COMPAT, is set to 2 or above, it will change over to using the > new, clean functionality. This will of course be accopmplished easily by > setting the variable at the top of debian/rules. This is the right solution. I think with a few tweaks to dh_make (a lot of people use this don't they?) it could be very easy to implement the change cleanly. > So what remains is figuring out what to change. I'm looking for feedback on > this, so if some aspect of debhelpor has bothered you but couldn't be > changed without breaking backwards compatability, now's the time to bring it > to my attention. Here's some things I could change: Comments littered about as I feel like it. => Stuff I don't comment on you're free to consider my opinion to be "go for it!" > * Standardize on the name used for the temporary build directory of a > package. Currently it's debian/tmp/ for the first package and > debian/<package>/ for other packages of a multi-binary package. I'm > considering debian/<package>/ for all packages, or perhaps > debian/tmp/<package>/ or perhaps debian/<package>-tmp/ . Of course making > this change means a certain amount of changes will be needed to make any > package work with v2. I would go for debian/package or debian/tmp/package. One of those, anyway. I prefer the former but it might not be possible if you go with debian/foo below. > * dh_installmanpages needs to be made much smarter, or much stupider. I > prefer making it stupider, it's much too DWIM-ish already. > smarter - parse .TH lines in manpages, look at binaries with names > matching manpages do anything else possible to get manpages > installed into the right directory and section. (#16933, #17061) > stupider - stop automatically finding manpages, require the user to tell > it what files are man pages and where they go. Much more > consistent with other debhelper programs. more stupid. Less I have to do by hand getting around current behavior. > * I've observed that large multi-binary packages end up with an unruly > debian/ directory with all the <package>.* files in it. It may make sense > to make debhelper use debian/<package>/* instead. Of course this requires > that directory is no longer used as the temporary build directory. I actually think that things would be cleaner looking if the files were foo.package rather than package.foo, but that might be too much of a change to make. > * Debhelper could be changed to look at only debian/<package>.<foo> instead > of looking at debian/<foo> also as it does in some cases now. The advantage > is just a simpler UI, you don't have to be concerend about what's the first > binary package listed in the control file anymore. A disadvantage is longer > filenames. This could be combined with the subdirectory idea, giving us > debian/<package>/foo, but that seems a little silly if your package only > generates one binary package. I wouldn't object to that. -- Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBE The Source Comes First! ------------------------------------------------------------------------- "my biggest problem with RH (and especially RH contrib packages) is that they DON'T have anything like our policy. That's one of the main reasons why their packages are so crappy and broken. Debian has the teamwork side of building a distribution down to a fine art."
Attachment:
pgpYyfIlEpbhF.pgp
Description: PGP signature