Various notes on /usr unification

Posted Feb 28, 2012 2:00 UTC (Tue) by russell (guest, #10458)
Parent article: Various notes on /usr unification

There is bigger picture with this kind of churn. Obsolete knowledge, processes, scripts,... This eventually leads to these things having to updated and re-learnt. Raising the costs (for little benefit) of supporting a linux environment.

Various notes on /usr unification

Posted Feb 28, 2012 8:59 UTC (Tue) by niner (subscriber, #26151) [Link]

On the other hand it will lower future costs by having less to learn. Two instead of four directories with binaries for example is definitely a step in the right direction.

Various notes on /usr unification

Posted Feb 28, 2012 14:32 UTC (Tue) by SEJeff (guest, #51588) [Link] (9 responses)

Am I the only one who uses PATH here? Sure, hardcoded stuff will change, but thats exactly the beauty of PATH, not worrying about that.

Various notes on /usr unification

Posted Feb 28, 2012 14:38 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (8 responses)

ISTR there are definitely contexts where you either shouldn't be trusting PATH at all, or should be forcing it to a known value yourself. (#! lines are one of them, IIRC.)

Various notes on /usr unification

Posted Feb 28, 2012 14:41 UTC (Tue) by SEJeff (guest, #51588) [Link] (4 responses)

Very true, but that also depends on the context. For virtualenv + python as a general rule, it is best to do:
#!/usr/bin/env python

Something that isn't pointed out is that people who aren't ok with this move don't have to use Fedora / a systemd distro moving to this model. They could fork fedora or build their own distro. It isn't as though distributors are forcing a free distro down your throat :)

Various notes on /usr unification

Posted Feb 28, 2012 17:43 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

anything other then "#!/usr/bin/env python" is essentially broken, unless your specifying a specific python version, in which case it should be "#!/usr/bin/env python2.8" or whatever.

Various notes on /usr unification

Posted Feb 28, 2012 20:39 UTC (Tue) by lindi (subscriber, #53135) [Link] (1 responses)

http://www.debian.org/doc/packaging-manuals/python-policy...

seems to give quite opposite advice at least for official debian packages:

"Maintainers should not override the Debian Python interpreter using /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python."

Various notes on /usr unification

Posted Feb 29, 2012 16:10 UTC (Wed) by cortana (subscriber, #24596) [Link]

That document is aimed at Debian package maintainers. Stuff shipped by Debian is supposed to to use Debian's own Python interpreter, hence hacks like running python via env are not permitted.

Various notes on /usr unification

Posted Feb 28, 2012 20:43 UTC (Tue) by samroberts (subscriber, #46749) [Link]

I think env itself is /bin/env instead of /usr/bin/env on some unixen, though it might be in /usr/bin for all linux distros, which makes it the kind of thing the unification might help.

Various notes on /usr unification

Posted Mar 5, 2012 9:53 UTC (Mon) by jschrod (subscriber, #1646) [Link] (2 responses)

But with /bin being a symlink to /usr/bin this would actually work, for once.

Not like now, where you can't write a bash script for both Linux (/bin/bash) and FreeBSD (/usr/bin/bash) without using #!/usr/bin/env. Then it could just be /usr/bin/bash and we would be done. Just as in Solaris, since many years.

Various notes on /usr unification

Posted Mar 5, 2012 10:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I never understood why can't we just write:
>#!bash
or
>#!env bash

instead of using absolute paths.

Various notes on /usr unification

Posted Mar 5, 2012 12:12 UTC (Mon) by jwakely (subscriber, #60262) [Link]

You can, but it means the same as #!./bash so probably doesn't do what you wanted.

Various notes on /usr unification

Posted Mar 1, 2012 8:32 UTC (Thu) by AndreE (guest, #60148) [Link]

Yes, specific knowledge becomes obsolete because the entire system is more predictable. That is a good thing.

I don't think you are going to convince anyone that having to learn the arbitrary determinations of binary and library location (that differ from distro to distro) ,is a better state of affairs than knowing everything will be found under /usr