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
