Re: conflict/replace/provide

[Joey Hess <joey@kitenet.net>]

Josip Rodin wrote:
> Would I convert the package to debhelper if I thought that debhelper
> is stupid? :) I just noticed how abnormally dh_installdirs behaves
> in different situations. For example, when called with -plibxpm4 <dir>
> it will not create debian/libxpm4/<dir>, but debian/tmp/<dir>. But,
> a line just after that, when I call it with -plibxpm4-dev <dir>, it
> creates debian/libxpm4-dev/<dir>.

The behavior is this:

If building a source package that generates exactly 1 binary package,
debian/tmp/ is used for the temporary directory of that package.

If building a source package that generates more than 1 binary package, the
first binary package listed in debian/control will use debian/tmp/ as it's
temporary directory. Each additiona package, however, will use
debian/<packagename>.


So, when you call dh_installdirs with -plibxpm4, it's acting on the
"libxpm4" package, which I guess is the first binary package listed in
debian/control. So it will use debian/tmp/

Then when you use -plibxpm4-dev, it's acting on "libxpm4-dev", which is
listed later in debian/control, so it uses debian/libxpm4-dev/

If you want it to use a different temporary directotory, you can always use
-Ptmpdir, which will force the debhelper command to use "tmpdir" as the
temporary directory.


This design is admittedly, a little wacked. Unfortunatly, I inherited it
from debstd. If debhelper hadn't been mostly compatable with debstd in the
beginning, it probably wouldn't have caught on. But now I'm left with debstd
compatability-cruft. One of these days, I'm going to figure out how to get
rid of it w/o breaking backwards compatability too badly. (I hope.)

> And when I try that same thing in another target, it will create
> debian/package/<dir>, and wouldn't even think about debian/tmp/.

Are you sure? That would be a serious bug in debhelper.

-- 
see shy jo