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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
