would /usr merge be advantageous for TCL in any way?

[GNUser]

Several *nixes (Debian, Devuan, Arch, Fedora, Solaris, possibly others) either have already implemented or will soon be implementing "merged /usr" where /{bin,sbin,lib,lib64} are just symlinks to /usr/{bin,sbin,lib,lib64}

Supposed advantages of this filesystem hierarchy are outlined here.

I know that in TCL there is the convention of /usr/local/{bin,sbin,lib} being reserved for extensions. A merged /usr would not interfere with this.

Would a merged /usr in TCL be more trouble than it's worth? More elegant but not actually beneficial? No trouble to implement and potentially beneficial in the long term?

I'd be curious to know the TCL developers' opinion about merged /usr. I admire you guys and greatly value your opinions because they have proven to lead to the best result (Tiny Core Linux).

[mocore]

Supposed advantages of this filesystem hierarchy are outlined here.

related (coincidentally i was just reading about this topic @ )
https://www.devuan.org/os/announce/excalibur-usrmerge-announce-2024-02-20.html
... i guess Debian adaptation would affect any future? dcore.

[GNUser]

FYI - I remastered TCL15's corepure64.gz with merged /usr as an experiment. Steps were completely naive:
1. Put all of /bin contents into /usr/bin. Then repeat for /sbin and /lib
2. Delete the now-empty /bin, /sbin, and /lib directories
3. In terminal:

Code: [Select]

# for i in bin sbin lib; do ln -s /usr/$i /$i; done

I'm happy to report that a remaster created in this way 100% Just Works.

Not that I'd use such a TCL mod as daily driver, of course--only vanilla TCL is acceptable to me. I just wanted you guys to know that if it would be advantageous for the TCL project to jump on this merged /usr bandwagon at some point in the future, it would be a trivial change with no breakage as far as I can tell.

[patrikg]

Funny facts about this issue you can see this part of video with Rob Landley explain the funny way why!!

https://youtu.be/Sk9TatW9ino?t=4768

[curaga]

My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.

[gadget42]

i would like to see all the previously written documentation/textbooks/tutorials/etc stay as accurate and relevant as possible for as long as possible
(and in my honest humble dinasour opinion the systemd/windowsification crowd believes it cannot sever these links fast enough to suit whatever change-agents they serve)

[patrikg]

I like this idea a lot, you can then remove some search path's, in the PATH.

To throw some wood on the fire, so how do we approach the /opt directory.
Maybe we should also talk a little about it too.

[polikuo]

This idea is new to me and I like it.
I write awk script a lot, it annoys me that the paths across distros are not consistent.
Just a quick example to show you all.

Normally, you'd think finding the path with env would be simple enough

Code: [Select]

#/usr/bin/env awk
However, the proper way to invoke an awk script is actually (note the '-f' flag)

Code: [Select]

#/usr/bin/awk -f
If you think appending that flag to the first method would do, you're wrong.
(This won't work)

Code: [Select]

#/usr/bin/env awk -f
The shebang of a linux script is always treated as literal.
Which means, the system will look for an executable called 'awk -f'
Obviously, it won't find anything, the script won't run.

I believe this is the scenario what they are trying to fix.
By putting everything in the same place so nobody has to fix file path again and again.
Come to think of it, it annoys me whenever the downloaded python modules are yelling for file path.
Perhaps they are after this one.

[GNUser]

(This won't work)

Code: [Select]

#/usr/bin/env awk -f

Hi polikuo. I've run into that problem before and it's a pain in the neck.

Dealing with the problem of /usr/bin/foo vs. /bin/foo in hardcoded paths is annoying because the purpose of the distinction is unclear at best. So the main selling point for me is that by merging and providing symlinks at filesystem root for compatibility, we eliminate needless complexity and never have to deal with a broken hardcoded path because of this distinction again because either path works!

Dealing with broken hardcoded paths because of applications that are unaware of the TCL convention of using local for extension-derived executables and libraries is a different story. Here the distinction serves a clear purpose for us.

My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.

Hi curaga. Thank you for sharing your thoughts on this. If it's "no advantages and no downsides" from a technical perspective but a small cosmetic advantage (leaner root filesystem) and a small practical advantage for users (fewer broken hardcoded paths), would you consider /usr merge for TCL16?

[curaga]

Yes, fine for TC16.

[GNUser]

Well, that's exciting! Thank you. I do think it is a slightly less complex setup, which suits TCL well

[polikuo]

FYI - I remastered TCL15's corepure64.gz with merged /usr as an experiment.

My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.

Just sharing some thoughts, my ideas keep sparking.

It can actually be beneficial for our extensions.

When making extensions for scripting languages such as bash, perl, python, php ...etc,
it's quite often that we have to make symbolic links manually. (usually via startup script)

Code: [Select]

ln -s /usr/local/bin/bash /bin/bash
When doing that again and again across all the architectures, it's inevitable for the maintainers to leave things out when ones get tired. (such as permissions or typos regarding to the startup script)

If we create symbolic links in INITRD instead

Code: [Select]

cd ROOT
mkdir -p usr/bin
for i in bin sbin lib; do ln -s /usr/$i $i; done
ln -fs /usr/local/bin/bash usr/bin/bash
It relieves the pain and prevents unintended omissions.

[GNUser]

Hi curaga. Another thing to consider for TCL16 is "sbin merge". The Gentoo script that does "usr merge" does "sbin merge" at the same time. FWIW Arch adopted both merges in 2013.

I tested "usr merge" + "sbin merge" on TCL15 x86_64. It is trouble-free, as expected. I love the beautiful simplicity of the end result: No need to guess if an executable is in /bin, /sbin, /usr/bin, or /usr/sbin because they all live together in /usr/bin The gain in cross-distro compatibility (due to support for any and all hardcoded paths) is just an added bonus.

[curaga]

sbin still has a purpose, root-requiring stuff, so not sure on that one.

[GNUser]

Yes, at least sbin has a purpose. Debian/Devuan did not do sbin merge (i.e., kept /usr/sbin as a real directory).