Re: Getting dh_install to do what we need
Thomas Goirand <zigo@debian.org> writes:
> Disclaimer: I didn't write any multiarch packaging (yet).
>
> The incentive for doing all this seems to be multiarch. Why
> instead don't we have a mechanism to have variables in
> debian/*.install instead, or a dh_helper to move things to
> the multiarch folder instead of /usr/lib (or anything you would
> find a better mechanism), so that we don't have to use tricks to
> make files reach the correct destination?
Apart from the reason explained in debhelper's git history, I can offer
another: variable substitution would be an incompatible change, as it's
perfectly legit to have '/usr/bin/${oh hai I broke your system}' or
'/usr/lib/${DEB_HOST_MULTIARCH}' files.
So, we'd need a flag to turn on variable substitution. Perhaps a compat
level would be enough - I don't know, nor do I care.
> Putting manual efforts into moving things to the correct
> multiarch folder seem to be quite annoying, the fact that
> it would be in debian/rules or in debian/*.install doesn't
> change much the issue: in both case we need to put efforts
> into it, which can lead to all sorts of various issues which
> wouldn't happen if we had the correct automation.
How much effort is a chmod +x, and adding 1(!) line to the .install
file?
Compared to writing overrides, it's less effort. Compared to just
writing the variable and expecting it to work, it's two commands more. I
believe that's not much.
On the other hand, though, making it obvious that it's a script, and
there's magic (= variable substitution) going on, it's much more clear
to have it executable. Otherwise you'd have to look at the compat level
to see if it's supposed to do some tricks or not.
I don't know about you, but I hardly ever look at compat levels. An
executable file in debian/ is much easier for me to notice.
--
|8]
Reply to: