Debian Sticking With Merged /usr Plan

[pal666]

debian is like fedora, but 7 years late

[pal666]

I must admit my own inclination would be to merge the other way, into the root folders, and ditch /usr,

/usr is readonly, root folder is read-write

[Grogan]

*lol* that's the same as saying "/bin is easily deleted and a single point of fragility"

No, it's not the same as a directory. Tar (gnu tar) for example would replace the symlink if it's a directory in the archive. In the case of a directory, if the archive had bin in a skeleton, it would simply merge directories (i.e. do nothing if the directory is empty in the skeleton, or put files in it if not)

A mishap in package creation, a third party installer for something, a user converting a package, these could replace the symlinks. Boom.

I didn't know Solaris started doing this, my first exposure to it was Arch several years ago. At the time was horrified and vowed I wasn't having that, but I'm getting over it.

[ssokolow]

POSIX compatible shell !== bourne (again) shell

Having slept (I responded to you after getting so into something that I'd pulled an all-nighter without noticing), I'd like to correct a prior response of mine.

POSIX does require something like a Bourne-compatible shell in that the POSIX shell is a Bourne derivative, just like every other shell still in active use today. (Aside from whatever use you still see of shells which are purely csh-descended and not Bourne/csh-switchable like zsh.)

As for your current response, the specified POSIX shell is a Bourne shell dialect which is most similar to one of the early Korn shell versions. (Source: The bash manpage.)

And, remember, Bash is essentially an enhanced Ksh, which is, in turn, an enhanced Bourne shell.

Which is why I think the shebang is unnecessary. I don't care about the shell. It will run on any POSIX shell.

It also lies on the executable status and suddenly this isn't a shell script anymore if I remove the shebang. My file is still marked as executable even without a shebang in it, and I can still execute it (if I have the .sh extension or if I figure out how to enable the setting to execute files like that guy on Fedora reported).

The .sh extension has nothing to do with it unless you're using Zsh. libc and syscalls hand off to the kernel, which only checks the magic number (0x7F 'E' 'L' 'F' for ELF files, '#' '!' for scripts) to identify how to exec the file.

With Shebang:

% printf '#!/bin/sh\necho FOO' > test.sh
% chmod +x test.sh
% python -c "import os; os.execlp('./test.sh', './test.sh')"
FOO

Without Shebang:

% printf 'echo FOO' > test.sh
% chmod +x test.sh
% python -c "import os; os.execlp('./test.sh', './test.sh')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/os.py", line 329, in execlp
    execvp(file, args)
  File "/usr/lib/python2.7/os.py", line 346, in execvp
    _execvpe(file, args)
  File "/usr/lib/python2.7/os.py", line 370, in _execvpe
    func(file, *argrest)
OSError: [Errno 8] Exec format error

The behaviour you're observing is down to your shell's fallback behaviour where, if you try to run a file that's marked executable and it has no recognizable magic number, it'll do its own internal decision-making.

Zsh is smart about it and supports extension-based associations. Bash and other less fancy shells will just assume that anything without a recognizable magic number is a shebang-less shell script and try to execute it.

% cp /usr/share/icons/Tango/16x16/actions/add.png .
% chmod +x add.png
% ./add.png
[Oops. My Zsh `alias -s {jpeg,jpg,JPEG,JPG,png,gif,xpm}="$IMAGE_VIEWER"` line kicked in.]
% mv add.png add.foo
% ./add.foo
zsh: exec format error: ./add.foo
% mv add.foo add.png
% bash
You are a fluke of the universe; you have no right to be here.
$ ./add.png
./add.png: line 1: $'\211PNG\r': command not found
./add.png: line 2: $'\032': command not found
./add.png: line 3: syntax error near unexpected token `$'-\017S''
IHD(-S<PLTE4e�4e�}���׃�؆�ِ�ڒ�ڔ�ە�۟����������������������tRNS��AC�IIDATxc 02110   0@��`���$,($�|L.N┴6V°┼&ý66ýýý┌°▒Zýý├"$␤ý:ý␍IENDýB◆ý'
⎽⎽⎺┐⎺┌⎺┬@└⎺┼⎺┌␋├␤:·/D␊⎽┐├⎺⎻/⎻▒┼␍⎺⎼▒$ ^C
⎽⎽⎺┐⎺┌⎺┬@└⎺┼⎺┌␋├␤:·/D␊⎽┐├⎺⎻/⎻▒┼␍⎺⎼▒$ ⎼␊⎽␊├
[Terminal resets because "⎼␊⎽␊├" was me typing "reset".]

If you were using a non-Bourne-compatible shell like csh or tcsh, you wouldn't be able to run shebangless Bourne-family scripts. Likewise, if a csh/tcsh script were to omit its shebang, Bash would fail to execute it.

[Grogan]

come on when you untar something blindly as root you have way bigger problems and even if it happens everything from the distribution still would work to re-create the symlink

In that case, great. (e.g. a script in the initramfs... though I don't use one myself, that would solve the problem for the people I would be concerned for)

OK, major packaging systems won't do that. I agree. I'm a bit of an alarmist at times when it comes to change, and I distrust symbolic links used in that manner but I'm starting to see merits. (I did read the freedesktop rationale you gave me).

given that it happened on Fedora 7 years ago and RHEL7 is out there in the meantime for years and other distributions followed it don't look like you get over it, otherwise you won't make a fuss after that much years just because Debian is late to the party

I haven't used Fedora since Core 2, so I wouldn't know. I've had only anal versions of RHEL/CentOS on servers since (e.g. CentOS 6.x, pre-systemd is the newest I've got). As I said, Arch Linux was the first place I saw it (long time ago) and I thought they were off their rockers at the time.

This didn't hit *buntu until 19.04 either.

I've been a bit sheltered because until somewhat recently I've just used DIY type distros. I still prefer simplicity, but I'm tired of fighting. Currently enjoying using package management for most things.

I suppose that what to take away from this is that everyone needs to do it, then it won't matter. Distros, upstream source releases... once every "make install" or equivalent stops putting stuff in those directories it will be a non issue.

[LaeMing]

/usr is readonly, root folder is read-write

Is /bin read/write? /sbin? Is there any rule against direct sub-folders of root not being read-only? (Obviously not since, as you so sagely pointed out, /usr is read-only)

[Grogan]

why in the world do you think you need the initrd for that?

* /usr/bin and /usr/sbin are in PATH
* the whole distribution is linked against /usr/lib64
* your basic OS just works without the symlinks

I meant, to regenerate the symlinks if the system can't boot. How would the system boot (init) if something happened to /bin or /sbin, or /lib if they got replaced with empty directories if not using an initramfs stage? When /sbin/init or /bin/systemd are symlinks to /usr/lib/systemd/systemd.

I don't know, I guess I'm asking if the kernel will try to execute /usr/sbin/init nowadays.

[Grogan]

I meant, to regenerate the symlinks if the system can't boot. How would the system boot (init) if something happened to /bin or /sbin, or /lib if they got replaced with empty directories if not using an initramfs stage? When /sbin/init or /bin/systemd are symlinks to /usr/lib/systemd/systemd.

I don't know, I guess I'm asking if the kernel will try to execute /usr/sbin/init nowadays.

I just had to answer my own question. The answer is evidently, no.

I happened to be in my kubuntu setup after playing some games, so I mounted up my Arch filesystem and deleted the symlinks and replaced them with empty directories and tried it. Kernel panic, no boot for me. (Custom kernel, no initrd)

Easily fixed, of course (because I know what I did).

[Murple]

Yes, you are missing that this news is about Debian and not Arch. So is there a point to your comment other than you being a typical Arch Linux fanboy/girl?

The news is about the /usr merge. I guess my point is that 1) Debian is a little behind as others have done it along time ago 2) the sky didn't fall in 3) I'm surprised it is even still being discussed. Thanks for the rudeness.

[pal666]

Is /bin read/write? /sbin?

you are getting it backwards. you can read from readwrite partition. you can't write to readonly one. main benefit of readonly /usr is it can be shared between many systems. but to answer your question, they are both readonly and symlinked to /usr/{s,}bin

Is there any rule against direct sub-folders of root not being read-only? (Obviously not since, as you so sagely pointed out, /usr is read-only)

obviously 3 separate readonly mounts is 3 times more than 1. and how your stupid idea of ditching /usr would work in this case? by making 15 readonly submounts in / and symlinking /usr/* to them?