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

debhelper design change - RFC (long)



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
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: