Hi,
Just to chime in to list some real world cases where env variable
substition would have been useful, but lacking it I had to create
some workarounds:
popt[1], and ncurses, have now install.in and links.in, which are
then preprocessed to the actual files. Wireless-tools[2] avoids
template files, but gets rid of .links file and instead does the
ln -s command manually in the rules file.
All these source packages have in common that the split libraries in
/lib/ with development stuff under /usr/lib/.. For the more usual
/usr/lib only libraries, env substition is not mandatory usually.
We can just replace install files /usr/lib/*.so.* with /usr/lib/*/*.so.*.
But that is a potential trap, as packages could just fine install stuff
under subdirectories of /usr/lib which might not be relative to --libdir.
And still, we have cases like glib2.0, where the upstream buildsystem
forces building many copies, making it neccesary to use install.in files.
As a summary, it is possible to live without env substition built in
debhelper. But it means we need to add some common tasks to
debian/rules, exactly the things that debhelper usually lets
us avoid.
Riku
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638447
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642434
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org