Adding ~/.local/bin to default PATH

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/07/11 15:46, Genes MailLists wrote:
> On 07/28/2011 09:09 AM, Bryn M. Reeves wrote:
>> On 07/28/2011 01:41 PM, Genes MailLists wrote:
>>> On 07/28/2011 07:53 AM, Bryn M. Reeves wrote:
>>>> On 07/28/2011 12:46 PM, Genes MailLists wrote:
>>>
>>>>>   This is a good point. Especially when you start on a 64 bit box and
>>>>> login to a 32 bit (or other arch) - bin now makes now sense at all. You
>>>>> need arch specific bins (bin, bin64 etc).
>>>>
>>>> Currently Fedora only separates out the /lib* directories in multilib
>>>> installations - you'll find a mix of 32 and 64 bit binaries in the system binary
>>>> paths on these systems.
>>>>
>>>
>>>  which is fine for a 'system' which is 64 bit and may support 32 bit as
>>> well - its not fine for a 'user'  who logs in to a 32 bit machine from a
>>> 64 bit machine and now his binaries wont work.
>>
>> Separating bin paths like this would not solve the problem; anything that's only
>> present in one path or the other would still fail in the scenario you suggest.
>> You could equally install foo/foo64 or vice versa into the same directory.
>>
> 
>   I don't follow your thought here - if you have a bin64/ and a bin/
> etc and you have your shell initscripts decide (e.g. using uname -m)
> which of those to include in your PATH I think it does work ... provided
> you have (obviously) both (all) populated with whats needed...

But that is still going to be a convoluted mess.  For those poor users who
then have access to arm, ia32, ppc64, s390x and x86_64, you suddenly need 5
different ~/.local/bin directories ... And I've probably forgotten some arches.

~/.local/bin (or even ~/bin for that matter) as default in $PATH is going
to be a mess, no matter how you twist it.  Because of the architecture
issues.  For scripts it will of course work fine in most cases, but in the
moment programs begins to get installed in ~/.local/bin (or ~/bin), then
we're definitely on the wrong track.

Binaries are related to the hardware it's running on, and should not be
related to $HOME at all.  In my opinion, $HOME must be arch agnostic.

I begin to fear that not being stricter on the pure original purpose of the
directory separation from the original Unix days is going to bite us hard
soon.  /home is for *user data*, and not binaries to start with.  Advanced
users understands this, and understands what will happen when their
binaries are attempted started on a different arch via NFS mounts.  They
most likely also know what they're doing when creating ~/bin or similar
directories and updating their .*shrc.  Average user John Doe, doesn't
really need know this, and shouldn't really be bothered to care about
binaries in his $HOME directory.

So often the road to hell is paved with good intentions.  To have
~{/.local,}/bin in default $PATH is indeed a good intention at first
glance.  However, it might not be the best solution for everybody.


kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4xj/oACgkQIIWEatLf4Hem+QCgqEuDYWw2G+BMxNYuFxHoRnY7
6SUAn33zcXqwudsrVJEv4iQu0vQ0Kurm
=B1HH
-----END PGP SIGNATURE-----