Re: Getting dh_install to do what we need
Goswin von Brederlow <goswin-v-b@web.de> writes:
>>> override_dh_auto_install:
>>> debian/libfoo.my-install-script
>> [..]
>>
>>> This new feature stinks of black-box magic that will make people crazy
>>> trying to find/fix a prolem in somebody elses package. The thing that
>>> make cdbs so bad.
>>
>>
>> I beg to disagree. You made very good example why the former (your)
>> approach was a black-box indeed, whereas the newer one in fact
>> standardizes things in parts.
>>
>> See, in your case libfoo.my-install-script could be doing anything,
>
> The libfoo.install file can do anything too. It's an executable, which
> are turing complete.
So, neither solution is any better or worse than the other in this
regard. Both can do pretty much anything they want.
>> including but not limited to copying, moving, creating, changing a file
>> without any information on what's going on.
>> Now, by using that feature you are forced to generate a (dynamic) file
>> listing instead and everyone can execute that script and see the results
>> without /actually/ installing anything to a binary package.
>
> But the debian/rules file makes it clear that there is something more
> than copying going on. It points a big fat arrow at the
> debian/libfoo.my-install-script.
So does a +x on the install script. And if it needs to do anything more
elaborate than expanding a variable or two and copying, it can be better
documented, and have a less convoluted syntax than Makefile rules.
> With the automatic execution feauture you never know if there is magic
> going on under the hood or not unless you carefully check every single
> files permissions.
ls --color debian/, or find debian/ -type f -executable give good enough
hints, in my opinion, and quickly glancing over the results is quicker
than finding your way through a bunch of overrides.
>> Of course you could discuss whether executing scripts is necessarily a
>> better idea than having some semantically parsed *.install file magic
>> instead, but that's an implementation detail.
>> Up to now, you are all discussing why "chmod +x foo.install" is so much
>
> Note: With a debian.tar file you don't need the chmod I think. So
> debian/rules would give you no indication that there is a black-box
> thing happening via dh_install.
There's alredy a lot of magic happening with debhelper. If it learned to
expand variables instead of executable scripts, there'd still be
magic. Just different kind of it.
If one's curious, the answer is a find away. It's not hard. And most
executable scripts WILL be trivial. Especially if we manage to
standardise on executable-debhelper-file-helper-tool usage.
Again, look at dpatch. I belive that despite all its warts, it is a good
demonstration that executable magic stuff can be standardised.
>> worse than overriding dh_install by your own dark magic but you should
>> be realizing you just traded one black-box for another
>> not-so-black-but-still-very-dark-box.
>
> Let there be light.
>
> A lot of cases will also be like
>
> override_dh_auto_install:
> sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' < debian/libfoo.install.in > debian/libfoo.install
> dh_install
>
> Something I would find more readable than libfoo.install being a executable.
And I find this more readable:
$ cat debian/libfoo.install
#! /usr/lib/debhelper/dh_subst
debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/libfoo.so.*
$
But, the good thing is: you can do either! You can opt to not make your
files executable, and do the override magic, if so you prefer. Those of
us, who hate doing that over and over again, can use convenient helper
scripts to make the executable files trivial.
--
|8]
Reply to: