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
