Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> writes: > -On [20080502 07:51], Ben Finney ([EMAIL PROTECTED]) wrote: > >To my mind, the Python interpreter installed by a package as > >distributed with the OS *is* OS territory and belongs in /usr/bin/. > > That's the difference with a distribution, such as Linux, and full > OSes , such as BSDs or commercial Unix variants. They prefer to keep > a pristine state for the OS vendor files versus what the user can > opt to install himself, hence the /usr/bin - /usr/local/bin > separation.
Fine so far. /usr/local/ is certainly for "what the (system administrator) user opts to install themselves". > It effectively guarantees you can nuke /usr/local without ill > consequences for your OS. You say this as though it's a property that a GNU/Linux distribution doesn't have. But the "keep /usr/local/ untouched by OS packages" approach taken by GNU/Linux *also* means that /usr/local/ can be blown away without ill consequences for the OS. So I don't see why you draw that distinction here. The difference seems to be that Python is an OS-installable package on GNU/Linux, and thus gets installed to the OS-packaged location. So the default Python installation should work. Whereas if Python is *not* installed from an OS package, it's up to the sys admin to ensure that it works -- not up to my program. So I don't see the point in making it work by default, when what I want for my program is that it works *with the default Python*, not with some non-default installation. -- \ "Truth is stranger than fiction, but it is because fiction is | `\ obliged to stick to possibilities, truth isn't." -- Mark | _o__) Twain, _Following the Equator_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
