Any thoughts around here about /usr merge?

[ghmitch]

Does anyone around here have any thoughts about the /usr merge initiative currently being pursued by Red Hat? I think it is quite interesting in that having tiny top level file systems was a kludge from the start to avoid having to mount a huge /usr file system at boot. These days there are not many systems left that would still have a problem with doing that. So I kind of like the idea. But I am interested in seeing it discussed a bit since it seems to be in the pipeline at this point. - George

[andreano]

The only disadvantage (apart from packages that need to be changed, and the risk of breaking things) listed in the Fedora and OpenSUSE pages:
http://fedoraproject.org/wiki/Features/UsrMove
http://en.opensuse.org/openSUSE:Usr_merge

…is broken LSB compliance. There is no real long-term disadvantage.

If only we could get rid of the symlinks too… Every time I create a script beginning with #!/bin/sh, I feel bad.

[Max]

If only we could get rid of the symlinks too… Every time I create a script beginning with #!/bin/sh, I feel bad.

As you should. Your scripts should begin with #!/bin/zsh.

[Ken-Bergen]

If only we could get rid of the symlinks too… Every time I create a script beginning with #!/bin/sh, I feel bad.

What has that got to do with symlinks?

#!/bin/sh is only needed in scripts called where no path has been set as in boot scripts, scripts run by a user /root or other don't need it.

[doktor5000]

@Ken-Bergen: Without a shebang, how do you tell the script which shell it should use, if you want something special?
Also /bin/sh is only a symlink to the default shell on the system, but you can't be sure which that would be.

[martinw]

#!/bin/sh is only needed in scripts called where no path has been set as in boot scripts, scripts run by a user /root or other don't need it.

Only if the user is using a 'sh' compatible shell. I use 'csh', so any scripts using 'sh' syntax will fail if they don't have a shebang.

[Ken-Bergen]

My Dunce Cap is on and I'm headed to the corner for my timeout.

[andreano]

Sorry, I should have been more precise (and /bin/sh was a very bad example). The directories whose content will be moved into existing respectively named directories under /usr will be replaced with symlinks to those destination directories:

Quoting http://www.freedesktop.org/wiki/Softwar ... heUsrMerge

/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64

Not to be confused with

/bin/sh is only a symlink to the default shell.

which is further complicating business. I bet the doctor knows this perfectly well, but let's say /bin/sh was a bad example. For the curious, this one will be a double indirection:
/{bin→/usr/bin}/{sh→bash}

What I meant by feeling bad: Scripts starting with #!/bin/<insert your favourite interpreter> is cementing the path of the bin directory at /. I guess this is the primary need for the symlink from /bin to /usr/bin, but what else is a script writer to do? Should we begin writing #!/usr/bin/<insert your favourite interpreter> instead, or even #!/usr/bin/env <insert your favourite interpreter>?

Why not allow the directory part of the interpreter path be omitted (and let $PATH resolve it)?

Code: Select all

#!bash
echo "bonjour"

gives me «bash: bad interpreter: No such file or directory». If it worked however, I would not need to push antique paths on people, and feel bad for it.

[doktor5000]

Well, there will still be symlinks for backwards compatibility, as also indicated in the freedesktop site you linked, f.ex. /bin -> /usr/bin so this is actually no issue.