Optionally symlink directories at / to /usr

[dimkr]

This is #2445, re-opened.

This PR adds optional support for linking /bin, /sbin, /lib, etc' to their counterparts under /usr, as most major distros do these days. To enable: put USR_SYMLINKS=yes in _00build.conf, or an environment variable (USR_SYMLINKS=yes ./3builddistro).

This is required to get the package managers of these distros to work well. (I'm working on getting apt to work under dpup, and this is a blocker.)

And yes, this comes at a certain cost: you can't swap the kernel if the kernel package is going to replace your /lib symlink with a directory that has nothing but /lib/{modules,firmware}. It will break your system, hence change_kernels is out of the build when this feature is enabled.

#2779 works without this PR, but it's cleaner to have only one bin, sbin and lib directory, and that's what third-party packages for Debian or Ubuntu expect, so this might improve Puppy's compatibility with foreign packages.

---

Spoiler:

[peabee]

Symlinking libs can also really mess up sfs loading .....
I don't understand this desire to make Puppy "just like every other mainstream Linux distro" I'm afraid. We are in danger of throwing out Puppy's unique features in a rush to conformity!
However as long as it's "optional" and is not being forced on people then if you really want to make a Debian clone go for it.

[dimkr]

I don't understand this desire to make Puppy "just like every other mainstream Linux distro" I'm afraid.

I'm trying to replace PPM, a buggy and slow package manager, with a good one. What's wrong with that?

PPM is easily one of the worst parts of Puppy, and Puppy will be a much better distro without it.

Those who create SFSs will have to rebuild them, that's true, but that's a small price to pay for a good package manager.

[dimkr]

Symlinking libs can also really mess up sfs loading .....

To make sure we're on the same page: the symlinks are not between /lib/x.so and /usr/lib/x.so. Instead, /lib, the directory, is a symlink to /usr/lib.

It's true that existing SFSs built with /bin as a directory, etc', will break any Puppy built with this feature turned on.

However, the importance of SFS loading, as a package management mechanism, is decreased if users can simply apt install packages, or even use one of Debian's graphical package managers.

We are in danger of throwing out Puppy's unique features in a rush to conformity!

You should take a look at #2773. The result of building dpup from that branch looks identical to what you get if you build from testing. It doesn't remove or disable SFS loading and PPM, if that's what you mean by "unique features".

The only differences, compared to today, are 1) you can safely use apt and 2) 19 MB increase in size

I don't understand this desire to make Puppy "just like every other mainstream Linux distro" I'm afraid.

When this (#2771) PR is added on top of #2773, the result is cleaner, and Debian compatibility should be better. PPM, SFS loading and apt still work. But in addition, third-party packages for Debian, that run something from /usr/bin although it's in /bin under Puppy, won't break (because /bin and /usr/bin have identical contents, as in Debian and other distros).

However, this also entails incompatibility with some SFSs - those that put files outside of /usr and replace the /bin, /sbin, /lib or /lib64 symlink with a directory. I think it's safe to assume this is just a tiny minority, because most SFSs contain graphical applications like browsers and LibreOffice, and they should be under /usr.

IMHO, compatibility with more Debian packages > incompatibility with a tiny minority of SFSs.

However as long as it's "optional" and is not being forced on people then if you really want to make a Debian clone go for it.

Yes, it's optional. And as I said both here and in #2773: the result looks and behaves exactly like dpup, but ... with apt and better compatibility with third-party packages for Debian. It's not a Debian clone.

---

@peabee - Does this make sense? Did I address all of your concerns?

[peabee]

19MB just for a Package Manager is HUGE!
A really major advantage of .sfs is that they do not pollute the save area with code meaning that the save area is less likely to be accidentally corrupted and simplifying the establishment of a new save area if this is needed. They can also be renamed so that updates just involve replacing the sfs with a new version and rebooting.
If you want to make a system with different characteristics then go for it but I would prefer this was done with existing Woof-CE specialization mechaisms.

[dimkr]

19MB just for a Package Manager is HUGE!

This translates into 5-6% increase in dpup's size.

Don't you think that such a small increase is worth it, if the gain is easy installation of browsers, LibreOffice, VLC, GIMP and Steam? Don't forget dpup is on the small side (compared to other Puppies from 2021 and beyond), at about 350 MB.

I think a 350 MB distro with a terrible package manger (PPM) is a tough sell, when you can have a 370 MB distro with the most widely-known one, with access to the largest repo in existence.

[dimkr]

Forgot to mention another motivation for the so-called "/usr merge": a user just asked me how to install Wine, and the only thing I can say is that it's impossible to install a 32-bit Wine alongside the 64-bit one, and many games need the 32-bit one.

By using the same directory layout as Debian, one can add 32-bit libraries (under /usr/lib/i386-*). It's super easy to install Wine with support for both 32-bit and 64-bit executables using apt (#2779), once the directory layout is compatible with this.