Re: Getting dh_install to do what we need

[Goswin von Brederlow <goswin-v-b@web.de>]

Gergely Nagy <algernon@madhouse-project.org> writes:

> 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.

Oh, no. This was ment as debhelper directly supporting the substitution
for a select set of known variables (dpkg-architecture output basically
or even just the multiarch var). If you have "#! /usr/bin/dh_subst" then
you do have the executable script way.

> 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.

At a glance what does this do?

#!/bin/bash
while read SRC DEST; do
  case "$SRC" in
    (\#*|) continue;;
  esac
  case "$DEST" in
    (*/) ;;
    (*)  cp -- "$SRC" "${SRC%/*}/${DEST##*/}";;
  esac;
  printf -- "%s %s\n" "$SRC" "${DEST%/*}"
done << EOF
bin/foo bin/baz
bin/bla bin/
EOF

>> 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.

Till now joey has always taken great care of not breaking existing
sources when introducing new features. He has been verry good with using
the compat level to restrict known and unknown side effects of new
features from affecting existing sources. It seems with the latest one
he slipped up slightly.

MfG
        Goswin

PS: Thanks Joey for all the good work you have done with debhelper. A
minor disagreement about ONE new feature in no way lessens the gratitude
you deserve for the rest.