search

OpenMandrivaAssociation / distribution

OpenMandriva Lx is an exciting free Desktop Operating System that aims to cater to and interest first time and advanced users alike. It has the breadth and depth of an advanced system but is designed to be simple and straightforward in use.
https://openmandriva.org
8 stars 2 forks source link

Changing from standard FHS (with multilib) to some kind of multiarch layout? #2720

Open tpgxyz opened 5 years ago

tpgxyz commented 5 years ago

Change the filesystem layout for multilib. Some distributions have started going for stuff like /usr/x86_64-linux-gnu/lib instead of /usr/lib64, /usr/i686-linux-gnu/lib instead of /usr/lib etc., and that's a really good idea because it allows installing compat libraries for more than just one 64bit and one 32bit architecture. This is useful especially now that qemu binfmt-misc stuff is working well and transparently launches stuff built for other architectures (think wine on ARM being able to run x86 Windows binaries because it has access to qemu and i686/x86_64 libraries). With the current lib64/lib FS layout, e.g. a user on aarch64 may want to install an x86_64 libjpeg to please whatever binary-only application and an i686 libjpeg to please wine -- but they can't go to /usr/lib64 (where aarch64 stuff lives) nor /usr/lib (where armv7hnl stuff lives). We don't have to break compatibility with anything to do this -- /usr/lib64 and /usr/lib could be symlinks to the native 64 and 32 bit arches, so stuff hardcoding /usr/lib64 or /usr/lib would still find what it's looking for and install to the right place.

Conan-Kudo commented 5 years ago

I don't think we should do this at all. But if we want to do something like this, I'd rather do sysroot-style instead.

That is:

But doing this (or the Debian-style multiarch layout) will require changes to RPM to handle these kinds of co-installation capabilities... I'd previously explored this in the past and was working on a PR to rpm to handle elfdeps properly in this situation, which needs to be finished: https://github.com/rpm-software-management/rpm/pull/360

Conan-Kudo commented 5 years ago

I'd actually like to see us at least empty out /usr/lib and move 32-bit libraries to /usr/lib32, but I don't know what the compatibility issues will be in doing so.

Conan-Kudo commented 5 years ago

@tpgxyz @berolinux Note that any change will require us to implement OpenMandrivaAssociation/OpenMandrivaAssociation.github.io#12 first, because there are many things that need to be fixed as part of any variant of this, and OpenMandrivaAssociation/OpenMandrivaAssociation.github.io#12 will make this much easier.

Conan-Kudo commented 5 years ago

Also note that Debian-style multi-arch breaks binary compatibility for 32-bit libraries, because you can't symlink /usr/lib/i686-linux-gnu to /usr/lib. So that whole thing just breaks.

Again, in general, I think we should not do this.

berolinux commented 5 years ago

I agree that a sysroot-ish setup is better, because we can symlink /usr/i686-linux-gnu/lib to /usr/lib.

I think we should do this -- or alternatively find a better way to achieve the same (one need: Install x86_64 and i686 binary libraries on arm boxes so with qemu-binfmt set up, stuff like steam and wine can run -- probably too slow for a lot of things, but an impressive demo and possibly a good solution for someone who has that one binary-only Windows application without lots of CPU needs (let's say a bookkeeping app) thing holding back the switch to an Arm Linux box).

I currently don't see any better way of doing it.

Conan-Kudo commented 5 years ago

I think if we shipped Mock configs for OpenMandriva, we could do some creative things using mock to set up secure environments that emulate x86 systems.

As mock supports using qemu-user-static for emulating foreign environments, combining that with nspawn would allow for pretty secure environments that "look" like the target environment. That's a lot less likely to be brittle, and you can have the advantage of cheaply respawning them. We can do creative things using Btrfs or thinp LVM to reduce the amount of space taken up by each spawned instance running programs.

This would also give us native packaged stuff + containerization/sandboxing, which IMO is better for those weird Windows apps anyway. Who really wants to trust them to execute freely?

Conan-Kudo commented 4 years ago

Another idea: podman can run foreign architecture OCI ("Docker") containers when qemu-user-static is installed and configured correctly (in the same way that Mock can). So we can leverage toolbox with some cleverness to make foreign arch stuff work pretty well smoothly and quickly.

This would require us to start publishing multi-arch container images to a registry that supports this properly, like Quay.io.