python not working on RHEL6

Chris Angelico rosuav at gmail.com
Tue Oct 2 15:32:52 EDT 2018


On Wed, Oct 3, 2018 at 5:17 AM Thomas Jollans <tjol at tjol.eu> wrote:
>
> On 02/10/2018 19:22, Dan Purgert wrote:
> > Thomas Jollans wrote:
> >> [...] (preferably, not in /usr - that's for OS-installed files only.
> >> /usr/local is a nice place to put things you installed from source).
> >
> > While I agree that /usr(/bin) is incorrect, I believe that "for
> > OS-installed files only" is taking it a bit far.
> >
> > My (admittedly, dim) recollection of the FHS is that the /usr hierarchy
> > is for static[1] "user" binaries, libraries, and so on; while being
> > OS-agnostic (so long as that OS followed the FHS).
> >
> > [1] "Static" in terms of the relevant filesystem being able to be
> > mounted RO and not cause any undue headaches.  I don't believe that the
> > FHS writers ever meant to imply that executables and symlinks thereto
> > were to be immutable such that installation of new / upgrading of
> > existing software is rendered impossible.
> >
>
> You're not wrong, but there's still a fairly strong convention that
> /usr/{bin,lib*,share,include} are only populated by (in some sense)
> non-essential components of the OS only, with varying definitions of
> "the OS". On Linux, this tends to mean "everything managed by the
> package manager", while on *BSD, it tends to exclude extra packages and
> ports collection.
>
> Whether we agree on the terminology here or not, of course we can agree
> that you have to be bloody careful if you *do* decide to put things in
> /usr/bin yourself :-)

As a general rule, it's safe to get a *different* version of Python
and do a "make altinstall" (which the OP agrees was the original
intention). Whether that lands in /usr/bin or /usr/local/bin doesn't
actually make a difference - what matters is the $PATH and which
command you get when you type "python" or "python2" or "python3". On
my system (Debian GNU/Linux), /usr/local/bin is ahead of /usr/bin in
$PATH, so even installing into local isn't going to protect you. It
will quite probably protect system tools (since they should be
explicitly calling on /usr/bin/python2.6 or similar), but could well
mess up manual usage from the shell.

ChrisA



More information about the Python-list mailing list