Re: Getting dh_install to do what we need
Goswin von Brederlow <goswin-v-b@web.de> writes:
>> 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.
The same will be true for dh-subst using packages. Does it start with #!
$BLAH/dh_subst? Yes? Then it will copy and only copy files around, and
substitution works just like you'd expect it to work.
So, in this case, the difference is negligible, both can be trivially
understood.
However, it gives more flexibility to the maintainer, to do more complex
stuff, if so needs be. But, that won't be the common case. Why? Because
there's no point in overcomplicating things.
> 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.
I'd treat executable files that are not scripts as a bug. They most
probably don't have a shebang line, and that's just wrong.
Breaking buggy packages is not something I'd worry about. Especially if
the number is fairly low (and I expect it to be so, but feel free to
correct me with numbers).
> 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.
Yes. But once you see a familiar shebang, you're fine. And familiar
shebang is what you will see 99.9% of the time.
If you're so paranoid that you need to double-check a package so
throughly, you have to read debian/rules and control throughly too: you
never know when a package depends on something that provides a DH
sequence command that would happily rm -rf / away...
> 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.
Debian stopped allowing non-make debian/rules due to an unrelated
correction, and since then is trying to explain it wasn't so. (It
certainly wasn't intentional at the time.)
--
|8]
Reply to: