W dniu 07.06.2021 o 17:31, Larry Len Rainey pisze:

In Tumbleweed,

/bin /sbin /lib /lib64 are symbolic links to /usr/bin /usr/sbin /usr/lib and /usr/lib64

I can see that but why is /opt not a link to /usr/opt and all /usr/opt not there too?

Am I missing the reason or has no one thought of this yet?

my 2 cents

Because there's no /usr/opt defined in Filesystem Hierarchy Standard (https://refspecs.linuxbase.org/FHS_3.0/fhs/index.html).

On Tuesday 08 June 2021, Larry Len Rainey wrote:

In Tumbleweed, /bin /sbin /lib /lib64 are symbolic links to /usr/bin /usr/sbin /usr/lib and /usr/lib64 I can see that but why is /opt not a link to /usr/opt and all /usr/opt not there too? Am I missing the reason or has no one thought of this yet?

my 2 cents

The UsrMerge seemed to be primarily aimed at cleaning up the mess due to dual OS locations such as /bin and /usr/bin. The /opt hierarchy has never had this issue (it does perhaps have other issues - such as deciding whether something belongs in /opt or in the main OS hierarchy). Because the /opt hierarchy doesn't such merge issues, it's contents can be easily relocated to where ever you wish. If relocated, a mount or bind-mount can be used to provide the necessary File System Standard /opt location, for example, you could move it to /usr/opt and then add the following entry to /etc/fstab: /usr/opt /opt none bind,user_xattr,noatime 0 0 There is a similar situation for /usr/local, I never want local to be part of the OS volume, so I use a bind mount: LABEL=home /home ext4 noatime,user_xattr 1 2 /home/local /usr/local none bind,user_xattr,noatime 0 0 Bind mounts for such situations are often better than sym-links. Some applications behave differently when encountering sym-links, for example, some resolve and store the true path which then causes a problem should further relocating be necessary. Michael

Am Dienstag, 8. Juni 2021, 04:46:25 CEST schrieb Simon Lees:

On 6/8/21 2:20 AM, Larry Len Rainey wrote:

...

Even though packages that are from /opt install binaries to all the libraries and binaries in /usr ?

That is not really the recommended way to use opt these days.

...

Without /opt being in there the rollbacks might not be complete since /usr is a snapshot?

The 1980's requirements were that /opt had its own /opt/bin and /opt/lib so that system files were not touched. What happened because of that is PATH ended up with multiple /opt/bin appended to it (one for each package that went to /opt) I saw systems become unusable because the environment was 100% full and deleting the excess entries in PATH was required to get past that. I was out of the loop as to when that requirement was dropped. It was in the Motorola 68000 Unix distro. I ended up with the PC 386 Unix and that requirement was gone. So it is OK to put 3rd part parts in /usr/bin and /usr/ lib64 (via symlink) but not the other files.

These days its more common to create /opt/<AppName> and then either add /opt/<AppName>/bin to the path or for some graphical applications maybe link there .desktop file to /usr/share/applications and possibly link the binary into /usr/bin. This means that if you install two different 3rd party apps that both use libfoo they don't end up overwriting each other in /opt/lib it also means that in the case of having to roll back a snapshot the worst you will need to do is recreate any symlinks that you may have created since the last snapshot.

...

On 6/7/21 11:01 AM, Thorsten Kukuk wrote:

...

On Mon, Jun 07, Larry Len Rainey wrote:

...

In Tumbleweed,

/bin /sbin /lib /lib64 are symbolic links to /usr/bin /usr/sbin /usr/lib and / usr/lib64

I can see that but why is /opt not a link to /usr/opt and all /usr/opt not there too?

Am I missing the reason or has no one thought of this yet?

/usr is for the OS of the distribution /opt is for third party packages

Since the stuff is different and follows different policies, it got separated many, many years ago for good reasons (read the FHS for more). Merging them now again doesn't make much sense and would only create new problems for transactional-updates, image based installations and many more.

Thorsten

+ For me its all right - there is something like an "Eselsbrücke" /usr for Unix(Linux) System Recources and /opt for all other Applications Have a nice day. -- Richard Werth

John Paul Adrian Glaubitz wrote:

That "usr" stands for "Unix System Resources", is a myth. It's short for "user" and used to be the canonical location for the home directories [1].

Correct, and /usr/bin was a common writable directory intended to permit users to share their private programs. Official UNIX programs have been in /bin only these days. BTW: Man pages for the shared private programs from /usr/bin exist because Stephen Bourne wrote a cron job that every night checked whether a new binary did also result in a better/newer man page. He explained that on a talk on a Sun User Group meeting in 1990. When /usr/bin has been kidnapped by the system, people invented /usr/local as an "escape" and soon admins kidnapped /usr/local ..... This was the reason to invent /opt in 1987 in order to break the chain of similar mistakes. Jörg -- EMail:joerg@schily.net Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

"Bernhard M. Wiedemann" writes:

Rest in peace Jörg.

Yes, RIP Jörg. Funny that I am seeing this post today since I just finished fixing the permissions for cdrecord in order to burn an ISO (I am using permissions.secure which have problems with burning). Haven't need to burn anything in years. Charles

On Wed, Oct 13, 2021 at 11:06 AM jdd@dodin.org wrote:

https://lwn.net/Articles/872489/

I'm very sad, I had to communicate with him to fix some misunderstanding between him and openSUSE (he was extremely competent but may be a bit rough)

really a loss...

He was a massive troll but unlike most also a very talented, persistent , proficient os developer, may he rest in peace.