Hi,

-----Original Message----- From: Ludwig Nussel 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. Cheers, Guillaume

cu Ludwig

[1] list of affected packages: CoreFreq aws-efs-utils bbswitch biosdevname blktrace blog crash crystalhd-libs dpdk drbd drbd-utils elilo fedfs-utils fprintd gcc gcc7 gcc9 gdm glusterfs gnome-keyring google-authenticator-libpam google-guest-oslogin grubby hdjmod ipvsadm jfsutils kanidm kdump kernel-default-base kubevirt libewf libgssglue libnss_nis libnss_usrfiles libpwquality libreadline5 linux-atm live-net-installer lsb lxc makedev malcontent mariadb mcstrans mdadm mhvtl mingetty mingw32-cross-gcc mingw32-cross-gcc-bootstrap mingw64-cross-gcc mingw64-cross-gcc-bootstrap msr-safe multipath-tools munin netconsole-tools nfs-utils nilfs-utils nss-pam-ldapd oath-toolkit ocfs2-tools oddjob ooRexx open-iscsi openafs opie pam_ccreds pam_chroot pam_csync pam_dbus pam_krb5 pam_kwallet pam_mktemp pam_mount pam_p11 pam_passwdqc pam_pkcs11 pam_radius pam_script pam_ssh pam_u2f pam_userpass pam_yubico pcfclock pciutils pcmciautils perl-Bootloader policycoreutils polkit-default-privs readline6 reiserfs rpcbind rtl8812au rungetty samba scsirastools sdparm slurm snapper sssd supportutils sysconfig sysdig tcpd texinfo texinfo4 tomoyo-tools trousers tunctl ucode-intel v4l2loopback vhba-kmp virtualbox virtualbox-kmp xfsprogs xtables-addons

-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)

On Mo, 2021-06-07 at 11:46 -0400, Neal Gompa wrote:

On Mon, Jun 7, 2021 at 11:44 AM Guillaume Gardet wrote:

...

Hi,

...

-----Original Message----- From: Ludwig Nussel 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

On Monday 2021-06-07 17:15, Ludwig Nussel wrote:

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[...]

[1] list of affected packages: gcc

This will be e.g. "/lib/cpp". You can "fix" it for openSUSE, but chances are upstream may not take a patch to that end, because /lib/cpp is one of those nasty traditional paths that are considered API much more than anything else (quite like /lib/ld-xxx.so.N)

vhba-kmp virtualbox-kmp xtables-addons

Eh that's /lib/modules. I'd love for upstream to move to /usr/lib, but it may be an uphill battle.

On 6/8/21 5:34 AM, Martin Wilck wrote:

On Mo, 2021-06-07 at 12:35 -0400, Neal Gompa wrote:

...

On Mon, Jun 7, 2021 at 12:10 PM Martin Wilck wrote:

...

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.

But when is that? None of the rest of us peons get to know that.

Coming back to the original question - I could of course move e.g. multipathd to /usr/sbin now - for TW. But on SLE or Leap, I would run high risk of scripts (from the distro, 3rd party, qa, users, ...) breaking because they expect it in /sbin. I can fix the distro scripts (even that would be some effort to begin with, and pretty error-prone), but I can do hardly anything about the rest. I don't think we'd gain anything if I move the binary to /usr/sbin and create a separate symlink in /sbin. Therefore I believe strongly that multipathd in SLE will remain in /sbin. OTOH, I try to avoid growing too many differences between TW and SLE/Leap spec files, too, and keep conditionals in spec files on a comprehensible level. 

In this case at least, I find it pretty obvious that simply keeping /sbin is the least error-prone and the least problematic approach, and will automatically do "the right thing" after the usr merge in TW, as well.

I guess the way it could be done and they way we handle many other similar things is make the change now in tumbleweed and then leave it as is in SLE / Leap and it will automatically be made there in the next major release where it can be properly documented etc. Otherwise in the 6 months leading up to whenever we next branch tumbleweed for the next SLE release all of a sudden people will start to care about these things again and it will all happen at one in a mad rush and or get put off again. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Mon, 7 Jun 2021, Jan Engelhardt wrote:

On Monday 2021-06-07 17:15, Ludwig Nussel wrote:

...

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[...]

...

[1] list of affected packages: gcc

This will be e.g. "/lib/cpp". You can "fix" it for openSUSE, but chances are upstream may not take a patch to that end, because /lib/cpp is one of those nasty traditional paths that are considered API much more than anything else (quite like /lib/ld-xxx.so.N)

It is/was historically used by X for preprocessing some of its config files. It's not something "upstream" does, btw, it's more like an integration artifact. The gcc package has # Provide the traditional /lib/cpp that only handles C cp $RPM_SOURCE_DIR/cpp $RPM_BUILD_ROOT/lib/ chmod 755 $RPM_BUILD_ROOT/lib/cpp and it's a short script provided by said package: #!/bin/sh # Traditionally, /lib/cpp only knew about C. exec /usr/bin/cpp -xc "$@" moving that to /usr/lib might be possible (it's where it resides after UsrMerge), but then this doesn't make the API any less legacy ... I'll see to "fix" gcc7, but gcc9 should be dropped from Factory as soon as possible instead. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Martin Wilck wrote:

[...] Coming back to the original question - I could of course move e.g. multipathd to /usr/sbin now - for TW. But on SLE or Leap, I would run high risk of scripts (from the distro, 3rd party, qa, users, ...)

Obviously don't do that. If you have to backport a package from TW to SLE the old locations have to be used. Can be done with a conditional on %suse_version < 1550 for example.

In this case at least, I find it pretty obvious that simply keeping /sbin is the least error-prone and the least problematic approach, and will automatically do "the right thing" after the usr merge in TW, as well.

Yes. Also multipath-tools is an annoying case. It has the split built in upstream in custom Makefiles already. For that it would be worth a try to get rid of the split upstream. A backport could then move the files where there need to be in the spec file. Anyway, this is how it could look with current sources: https://build.opensuse.org/request/show/898310 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)