My point is that /usr/bin/python probably shouldn't be a core OS component. /usr/bin/python should be whatever I want it to be. The core OS-component should be something like /sys/bin/centos-python which I will never directly use, touch or even necessarily know about.
The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.
> /usr/bin/python should be whatever I want it to be.
Why /usr/bin/python? /usr/bin/ has been for ages the "system" area - why would you want to suddenly usurp it for yourself?
/usr/local/bin/python will on most Linux systems be executed ahead of /usr/bin/python, because /usr/local/bin/ usually precedes /usr/bin/ on the $PATH. Thus you can have your cake and eat it too.
> The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.
Linux distro makers agree with you - if you do not customize environment variables, user-installed software goes into /usr/local/ and the OS package-management (which can be considered "system" I guess) puts executables into /usr/{bin,sbin}.
This tends to work well as long as you keep in mind that everything outside of /usr/local/ (or your customized installation path) may at any update change subject to the will of the "system". I think this is a reasonable setup - it gives the OS vendor the ability to update the system, while giving you free reign in your /usr/local/ playground.
OS package-management (which can be considered "system" I guess)
This is where I and the distro makers disagree. When I use synaptic to install the latest version of foobar, that is not in anyway "system" and foobar should not be dumped in the same directory as core system binaries. There should be a directory that contains everything core to the OS (like python 2.4), which was only updated by the OS updater routine (which should be different from the update all the software I've installed routine). Then there should be a directory which contains everything I've chosen to install (like python 2.7) which is where everything that I install via whatever is the normal way to install things on that OS ends up. I don't care too much about what these directories are called, but having them be the same, as it is now, is not an ideal solution in my mind.
We're getting into the debate of what constitutes a "core system", and I'm afraid there's as many answers to this question as there are debaters.
As far as the update routines are concerned - you can already have those, by self-selecting which packages do you want to update. As a pro-active measure, you can even lock down packages which should never be updated.
This seems to be fine to me - the advanced user has the means to control the update mechanism, and the casual user can just do an all-encompassing "apt-get upgrade" or an equivalent to make sure that she has all the security fixes.
It seems like you want BSD ports, or some alternate package repository that has /usr/local as the root. The packages from the OS repository are the OS.
because, as the other poster mentions, /usr/bin has been a place for non-essential (not required by the machine to boot) software for thirty five years.
I know, but that doesn't necessarily make it a good solution.
I've been a sys admin for several large unix systems and variations on the problem Zed describes needed to be hacked around on each and every one of them.
I think we agree. If I were doing an OS now, I'd also ignore the FHS completely, but more to the point: I wouldn't use anything that remotely resembles it either.
/ would have one dir:
/myos
And all OS components are under there:
/myos/bin/python
People can install anything they want outside /myos, but I'd make it very clear that the OS owns this folder and it should not be modified.
I did a little work on this a while back - an LFS system is a good place to start. I was a little ambitious though - I wanted a pure C/python system with no shells (at all - just ipython) and no command scraping - just enough to start SSH and nginx.
It's a lot of work - I think I ended up trying to write an iproute2 replacement using ctypes and quit. I wonder if anyone else would be interested...
The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.