Re: Getting dh_install to do what we need
Chow Loong Jin <hyperair@ubuntu.com> writes:
> On 09/12/2011 02:10, Gergely Nagy wrote:
>> Chow Loong Jin <hyperair@ubuntu.com> writes:
>>
>>>> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work
>>>> for kFreeBSD and pretty much anything else out there too. An extra
>>>> /bin/sh never hurt anybody!
>>>
>>> Except that it forces your interpreter to be written in sh, which Debian doesn't
>>> like[1][2].
>>>
>>> [1] http://lintian.debian.org/tags/script-with-language-extension.html
>>
>> This is irrelevant, as it's only about the extension, and only about
>> scripts on the path. My proposal has no extension, and isn't on the
>> path, either.
>
> Sorry, I mixed it up with another post that mentioned /usr/bin/dh_multiarchify.
> I didn't realize you changed the path to /usr/lib/debhelper/dh_multiarchify.
It wouldn't apply in the /usr/bin case, either, since there is no
extension.
> I linked to the policy and lintian tag not because of an implied policy
> violation, but the general reasoning behind not permitting extensions in scripts
> on $PATH, i.e. that it causes the implementation language of the binary/script
> to be locked into the #!s of all its users.
Yup, and my script didn't have an extension.
> I'm guessing that dpatch-run had never needed its implementation language
> changed, but that doesn't necessarily justify locking the implementation
> language of your proposed dh_multiarchify into the #!s of all .install files
> which use it.
If the language ever needs to be changed, no problem: make the former
shell script a wrapper, that calls the real deal.
> Between "#!/usr/bin/env /usr/lib/debhelper/dh_multiarchify" and "#!/bin/sh
> /usr/lib/debhelper/dh_multiarchify", I think the former is obviously the
> superior choice, regardless of what dpatch used for the past 7 years.
Perhaps. In the long run, it doesn't matter, both get the job done, and
whether it's /bin/sh or /usr/bin/env is such a minor detail. And policy
still doesn't say a word about this case. Not even remotely.
But, I'm convinced: I'll use /usr/bin/env in the upcoming dh-subst
thingy.
--
|8]
Reply to: