On Mo, 2021-06-07 at 11:46 -0400, Neal Gompa wrote:
On Mon, Jun 7, 2021 at 11:44 AM Guillaume Gardet <Guillaume.Gardet@arm.com> wrote:
Hi,
-----Original Message----- From: Ludwig Nussel <ludwig.nussel@suse.de> Sent: 07 June 2021 17:16 To: factory@lists.opensuse.org Subject: Switch all packages to /usr?
Hi,
Now with the UsrMerge in place the question arises what to do with all the packages that still install files into /bin, /sbin, /lib and /lib64 without causing conflicts. The files end up in their counterpart in /usr anyway as rpm follows the directory symlinks. So technically there is no strict requirement to adjust those packages. In fact looking at Fedora 34 it seems they just live with that state.
So should we bother and change the remaining packages¹ too? Would make sense for consistency I guess. The biggest challenge is likely the kernel with the module directory.
We likely need to keep compatibility with Leap/SLE anyway. So, I would not bother with those packages.
No, we should actually fix it, because we already have an upgrade gate anyway. The fewer things in /, the *less* fragile things will be.
What harm can be done by installing to /lib after the usr merge? I agree we shouldn't accept new packages doing that, but those which did for the past 10 years - why can't they continue doing so?
That said, we've been partially UsrMerged for years, so SLE 15's current state of affairs is a bug.
You're free to think this way, but SLE has never claimed to be either fully or "partially" usrmerged. Calling this a bug is not helpful. I don't know the plans for SLE, but I doubt we'll see a usr merge there any time soon. Like it or not, but for some of us Leap/SLE compatibility does matter. If we are forced to use different installation paths for Factory and SLE, we'll get more Factory/SLE differences and more hassle when we need or want to promote Factory packages to SLE or Leap. I for one would clean this up when I update one of my package in a way that I know won't go into SLE any more anyway, but no sooner. Regards, Martin