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. 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)
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. 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 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. That said, we've been partially UsrMerged for years, so SLE 15's current state of affairs is a bug. -- 真実はいつも一つ！/ Always, there's only one truth!
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
On Mon, Jun 7, 2021 at 12:10 PM Martin Wilck <martin.wilck@suse.com> wrote:
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?
The issue with it is that if we're not proactive at fixing these things, it becomes more painful when they cause problems later on (and worse, land into the next SLE release!)
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.
We've been slowly implementing UsrMerge for over 9 years[1][2]. It first came up again nearly four years ago[3], and then came up again two years ago[4]. And now it's finally mostly implemented. [1]: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/T... [2]: https://en.opensuse.org/index.php?title=openSUSE:Usr_merge&oldid=51715 [3]: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/Z... [4]: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/4...
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.
But when is that? None of the rest of us peons get to know that. In many ways, I think that restriction has made it difficult for us to innovate because too many people have a SLE-first mentality to Tumbleweed. Maybe this is a consequence of not having a regular release anymore (I wasn't terribly involved during the time the classic releases existed), but it's frustrating when things are "stuck" because of SLE. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mo, 2021-06-07 at 12:35 -0400, Neal Gompa wrote:
On Mon, Jun 7, 2021 at 12:10 PM Martin Wilck <martin.wilck@suse.com> 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.
I don't know either, yet :-) I was speaking with the package maintainer hat on, not the SLE product strategy insider (which I am not).
In many ways, I think that restriction has made it difficult for us to innovate because too many people have a SLE-first mentality to Tumbleweed. Maybe this is a consequence of not having a regular release anymore (I wasn't terribly involved during the time the classic releases existed), but it's frustrating when things are "stuck" because of SLE.
I can't speak for everyone, but "SLE first" doesn't nail it. It's rather "let's not forget about SLE", or "let's not make things harder for SLE while making it easier for TW". I understand that your PoV is different, working cross-distro a lot. But please try understanding us, too. There is a lot of intertia in an enterprise distribution, for good and bad. 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. Martin
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 <martin.wilck@suse.com> 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
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)
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.
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)
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.
You don't necessarily have to apply a patch to move the files to /usr. Could be as simple as ln -s usr/lib %{buildroot}/lib in %install and adjusting the file list. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Tue, 2021-06-08 at 10:45 +0200, Richard Biener wrote:
I'll see to "fix" gcc7, but gcc9 should be dropped from Factory as soon as possible instead.
You are but one delete request away from that:
dependson gcc9 gcc9 : gcc9 gcc9-testresults
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 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.
Since meanwhile even the kernel went to /usr, I've filed bugs for the remaining packages. Compared to the kernel those should be peanuts to fix :-) PAM modules may use %_pam_moduledir, firmware package can use %_firmwaredir. There's nothing to be done for most kmps as they'll just move automatically as soon as a kernel with adjusted macros gets checked in. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
participants (8)
-
Dominique Leuenberger / DimStar -
Guillaume Gardet -
Jan Engelhardt -
Ludwig Nussel -
Martin Wilck -
Neal Gompa -
Richard Biener -
Simon Lees