Re: Getting dh_install to do what we need
+++ Thomas Goirand [2011-12-09 02:39 +0800]:
> On 12/08/2011 06:47 AM, Josselin Mouette wrote:
> > Closes: #235302, #372310, #235302, #614731,
> > Closes: #438601, #477625, #632860, #642129
> The incentive for doing all this seems to be multiarch.
It's not just multiarch. The list of bugs above covers a range of
cases where people want to do 'interesting' things with .install files.
The way this one changes solves all those bugs demonstrates the
power/flexibility of the idea. The question is, is it overkill for the
Yes, multiarch is the case that is by far the most common
requirement and appears to have prompted this change (
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614731 is the
relevant bug )
> instead don't we have a mechanism to have variables in
> debian/*.install instead,
That was my original suggestion. It has the advantage of being easy to
understand, but of course is not as flexible as this general solution
for 'do whatever crazy shit you need to do'.
There is often a tradoff between simplicity and flexibility. You could
argue that this errs somewhat on the side of being too flexible, but
maybe it's just really clever?
> or a dh_helper to move things to
> the multiarch folder instead of /usr/lib (or anything you would
> find a better mechanism), so that we don't have to use tricks to
> make files reach the correct destination?
> Putting manual efforts into moving things to the correct
> multiarch folder seem to be quite annoying, the fact that
> it would be in debian/rules or in debian/*.install doesn't
> change much the issue: in both case we need to put efforts
> into it, which can lead to all sorts of various issues which
> wouldn't happen if we had the correct automation.
> Comments anyone?
It does seem that multiarch is such a common case that there is a good
argument for having it dealt with in a standard way. That could be a
standard dh_multiarchify script as suggested somewhere else in this
thread (can we make a one-size-fits-all reliable multiarchify
script?). I'd have been perfectly happy with a special token,
substvar, or env var substitution, and I guess that could still be
done if it eventually seems still to be a good idea.
Seems to me that it'd be nicer to have installs something
But, ultimately I'm happy that there is now mechanism to solve this issue
fairly cleanly (assuming that the DEB_* env vars really are exported -
see elsewhere in this thread).
I wouldn't have done it this way, but then I'm nothing like as clever
as Joey is.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM