Ben Gertzfield has convinced me that debhelper's special treatment of the first package listed in debian/control isn't a good thing. I'm thinking about redesigning debhelper to act in a more consitent fasion. Of course, backwards compatability is very important. (Especially since people enjoy cutting on debhelper and debstd for backwards compatability issues. I really don't want to give you guys more ammo. ;-)
First, some background - each debhelper program can take parameters on the command line, as well as from a file in debian/. For example, dh_installdocs can be passed the filenames of documentation to install into usr/doc/<package>, and it also reads debian/<package>.docs for more filenames. If debhelper is working on building more than 1 binary package, then it treats the first binary package listed in debian/control specially. For this package and this package only, it uses the command line parameters. For all the other packages in debian/control, you must use the debian/<package>.docs files. (If I've lost you already, go take a look at the debhelper man pages and docs. I'm concerned about changing this behavior exactly because it is so confusing.) This can lead to confusing situations. Suppose the control file has 2 packages, foo is first, and bar second. If the maintainer tries something like: dh_installdocs -pbar README BUGS Then dh_installdocs is only acting on package bar. However, since bar is not the first package listed in debian/control, the 2 filenames specified are ignored. This is confusing. I've come up with a variety of different solutions, and am trying to chose between them: 1. Add a -f flag, that makes debhelper programs apply the command line arguments to all packages it's acting on. With this switch, you could use: dh_installdocs -f -pbar README BUGS And README and BUGS would be installed into usr/doc/bar/ Of course, you could also say this: dh_installdocs -f README BUGS And README and BUGS would be installed into both packages (since debhelper acts on both by default). Backwards - compatability problems: none, since the -f flag is a new flag. 2. Add a -f flag, like above, but it only makes the command line arguments apply to the first package you ask debhelper to act on. Then you could use the same command line as above, with identical effects, as well as things like: dh_installdocs -f -pbar -pfoo README BUGS This would make README and BUGS be installed into package bar only. Backwards - compatability problems: none, since the -f flag is a new flag. 3. Don't bother with the -f flag, make debhelper _always_ apply the command line arguments to the first package you ask it to act on. So, you could use: dh_installdocs -pbar README BUGS And README and BUGS would be installed into usr/doc/bar/ If you ran: dh_installdocs -pbar -pfoo README BUGS This would make README and BUGS be installed into package bar only, since it's listed first. And if you ran: dh_installdocs README BUGS README and BUGS would be installed into package foo only (since it's the first package in debian/control, just as happens today with the current debhelper.) Backwards - compatability problems: If someone accidentialy has the following type of command in their debian/rules today, debhelper's behaviour would change: dh_installdocs -pbar README BUGS With current debhelper, this is a no-op. If I implement option #3, then this installs README and BUGS into package bar. Let me stress that this is only a problem that will only happen if someone didn't understand how debhelper worked in the first place. Debhelper will do something different, but it probably wasn't doing what they wanted it to do before, either, since they didn't understand why it was acting as it did. I far prefer #3, I feel it's the cleanest way to go (it will simplify the man pages a lot), but its backwards compatability problems worry me. If people think #3 is too radical, I can easily fall back to #2, but it's not as clean. #1 doesn't appeal. Comments? -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .