Re: status update

> On 29 Aug 2016, at 19:17, Sam Steingold <[email protected]> wrote:
> 
>> * Daniel Jour <[email protected]> [2016-08-28 23:55:18 +0200]:
>> 
>>> pwd is also a shell built-in, so full path is necessary.
>> 
>> Hm, I understand why pwd may give (in case of symbolic links) a
>> different result as a non-builtin pwd. Why do we need the physical
>> (not logical, i.e. without the symlinks) path, though?
>> 
>> As for /bin/pwd ... this is a bad idea. /bin (the directory) is about
>> to die (ok, that's a bit drastic, I'm reffering to the "usr merge"
>> here), and there may be more than one pwd on a single system (this is
>> the main reason for this change, because it directly affects me. This
>> could be fixed downstream by the currently few affected distributions,
>> too. But in the future this might affect every linux distribution that
>> uses systemd.)
> 
> this is news to me.
> "/bin/cp" going away will break so much stuff that I doubt that anyone
> will seriously contemplate this.

I think what Daniel is suggesting here goes farther than the current goals
of the usr-move camp (see [1] and [2]). Traditionally, /bin and /usr (thus /usr/bin)
could live on different partitions and be mounted at different points in time. I
believe defenders of the usr-move idea will argue that there’s no good use case
for that anymore, so that /usr can just be assumed to be available whenever /bin
is assumed to be available. That does not mean that /bin/cp and the like go the
way of the dodo but rather that they might be symlinks to /usr/bin/cp, so that as
a package maintainer you no longer need to spend time thinking about what has
to go in /bin and what can go in /usr/bin instead. As a typical user you would not
notice any difference.

That said, I chimed in here to save the unit experts some typing, not because
I consider myself one (I don’t).


Elias

[1] http://0pointer.net/blog/projects/the-usr-merge.html
[2] https://fedoraproject.org/wiki/Features/UsrMove


------------------------------------------------------------------------------
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel