Gergely Nagy <alger...@balabit.hu> writes:
> Goswin von Brederlow <goswin-...@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.
Not quite. It implements support for renaming files during dh_install,
implementing the following syntax:
file path/
file path/new_name
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
directory.
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
debhelper-exec-rename both?
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.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wra1hk7k.fsf@frosties.localnet
