On 03/29/2017 04:52 PM, Tomasz Kloczko wrote: > On Wed, 2017-03-29 at 12:26 +0000, Nikolai Kondrashov wrote: >> I would say using env in the shebang line is useful. Particularly for >> portability. As a developer, I wouldn't like removing it from my programs. > > Portability is not an issue at all here in this exact discussed case because distribution resources as long as they are packaged into > binary packages they are ALL *already ported resources*. > You can provide 100% functional source code not depending on env and still able to produce resources to install with fixed location of > <interpreter>. This is not the rocket science. Right. I misread your message and answered in a hurry. I apologize for taking your time. I thought you suggested /usr/bin/env use must be fixed in upstreams. I'm OK with it being fixed on packaging, although I'm not particularly happy about it. >> Moreover, if your PATH is compromised, you're most likely screwed. > > Still .. if $PATH will be compromised removing using env decreases risk here > because removing using env attaches script to some fixed <interpreter> path. Yeah, it decreases risk, but not much. >> I understand, that env use in scripts makes is inconvenient in some cases, >> but I think that RPM build procedure and Fedora practices need to be fixed >> instead. > > So instead decreasing generally entropy you are proposing increase it .. by > introduce kind of JFDI :) Yeah, I was just trying to not increase it outside Fedora, but I realize now it is not likely to be affected. >> The number of packages using env in scripts alone shows that it is a >> widespread and useful practice. > > This is not about practice. > Generally using env comes from the time when when installing additional version of the <interpreter> was only civilised way fulfilling > some needs without changing distribution resources. > Second typical past scenario was when distribution not been providing <interpreter> and users have been installing it manually on top > of distribution in non arbitrary locations. > In other words always evn was more workaround than RightSolution(tm) and now it is part of the legacy which can be removed cleanly. > > Using env it is more *legacy badge* which needs to be dropped best in source code trees. > Producing patches and submitting them to source code maintainers will help get rid those issues. > If you will have look on those packages affected by env you will find that ~97-98% of all cases is related to prl and python. > Committing today in source trees paths to those two interpreters as located in /usr/bin will not hurt portability of such code on other > Unixes as they already provides exactly the same versions of those interpreters in the same locations as on typical Linux > distributions. > > Getting rid of using env is much more legacy related things. > Most of them comes from the the time when Solaris and other flavours of the Unixes where the dominant Unix on the market. Well, my concern was mostly about interpreters in different locations on different *nixes. > There is much more such legacies still embedded in source trees which now can be dropped, > Example: > > # dnf repoquery --whatrequires 'libnsl.so.1()(64bit)' \*.x86_64 | wc -l > Last metadata expiration check: 1:19:13 ago on Wed Mar 29 12:36:31 2017 BST. > 294 > > ATM in glibc libnsl provides almost only ABI/API used by NIS/YP/NIS+ NSS maps related binaries. > On Solaris the same library contains some base network sockets functions. > Of cource today using on Linux libnsl by some packages does not means that there are so many software is related to NIS/YP/NIS+ :) > > Many source trees maintainers which started own projects even recently coped base set of system detections where adding -lnsl to LIBS > was present. All such issues should be not fixed by something similar to plastering .. I agree, using -lnsl needlessly is bad. However, I suspect we might still need to keep it around for quite a while. Again, to help those programs that actually use it. Nick _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
