Re: Getting dh_install to do what we need
Gergely Nagy <algernon@madhouse-project.org> writes:
> 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.
Except that none of the existing sources do have one and it is verry
verry unlikely any 3rd party sourced have one either. It was also
discussed to even limit the substitution to a select few variables so
'/usr/bin/${oh hai I broke your system}' would not get substituted, even
if you had an evironment variable called "oh hai I broke your system".
So a compat level for that would be overkill. But totaly possible.
>> 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?
Times 2000 library packages. But that isn't really the point. Adding
${DEB_HOST_MULTIARCH} to the .install files isn't any less work.
> 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.
Would you really need to look at the compat level? Wouldn't seeing a
${DEB_HOST_MULTIARCH} in the .install file be obvious to everyone that
there is substitution going on and what it does? It is a rather common
syntax that should be familiar to every maintainer. Do you even need to
read the .install files? You do know it will copy and only copy files
around.
On the other hand we do have packages with executable debhelper files
that are NOT scripts. Debhelper currently breaks those. The execute
scripts feature should use a compat level. And then you would have the
situation you described, where you have to check the compat level and
every script.
Also an executable can do anything in any number of verry obscure ways. You
have to actualy read the script, check the shebang, see what the shebang
does before you can say wether the script will, for example, rm -rf / or
not.
Think of what this means for e.g the security team if they have to fix a
package that uses a .install file written in haskell. Debian stopped
allowing perl scripts for debian/rules for a reason and now dh brings
that back, at least in part.
MfG
Goswin
Reply to: