+++ 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 common case? 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 ) > Why > 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 like: debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/libpopt.so.* lib/${DEB_HOST_MULTIARCH} 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. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20111208193425.gj28...@dream.aleph1.co.uk
