Re: Getting dh_install to do what we need
Goswin von Brederlow <goswin-v-b@web.de> writes:
>> 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.
>
> Lets hope it stays at the level where you have a shebang (one of few
> well known tools) followed by the normal input. That would be relatively
> easy to get used to and understand. So you look at the .install file and
> then man dh_subst and you are good.
That's the idea. Similarly to the normal dh_* tools, where you look at
the man page, and you're good. ;)
> At a glance what does this do?
[...]
It triggers my "slap the maintainer silly" button. Other than that, it's
dead simple: copy a file from one place to the other (with possibly
renaming the file), with the file list following the while loop.
This also gave me an idea, and since this use-case seems to be common,
I'll probably rename my dh_subst thing to debhelper-exec-extras or
something similar, and include a little tool that will cover this
use-case aswell.
>>> 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).
>
> Around 17 sources for 3.0 (quilt) format. So nothing major. Could be
> some more for native packages.
So, the number is not fairly low, it's so low that it doesn't even
matter. :P
--
|8]
Reply to: