Re: Getting dh_install to do what we need
Gergely Nagy <email@example.com> writes:
> Goswin von Brederlow <firstname.lastname@example.org> writes:
>>> So, in this case, the difference is negligible, both can be trivially
>>> 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.
Not quite. It implements support for renaming files during dh_install,
implementing the following syntax:
The hack it does is to copy the file in the source directory to the new
name and then letting dh_install install it to the destination
And yes, like this it is a totaly ugly hack. Does it become better as
#!/usr/bin/debhelper-exec-rename or something?
> 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.
What if I want to do more than one thing? For example rename and do the
variable substitution. Should we have something like
#! /usr/bin/debhelper-exec-pipe debhelper-exec-subst debhelper-exec-rename
which would pipe the input file through debhelper-exec-subst and
Does any Debian port have the limit of only one argument for shebangs?
>>>> 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
Yes. Don't make a big deal out of this. It was just tickling my funny
bone. It isn't a showstopper.