Deprecating the %usrmerged macro
Hi! When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version. So I propose to remove use of the %usrmerged macro in spec files. Of course spec files could manually set it based on %suse_version if that's convenient. Spec files just shouldn't rely on an externally set %usrmerged anymore. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
On 27.12.22 11:51, Ludwig Nussel wrote:
Hi!
When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version.
is this then "%suse_version >= 1599"? I'd guess $HOWEVER_NEXT_ENTERPRISE_DISTRO_IS_NAMED 16 will also have usrmerge? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Stefan Seyfried wrote:
On 27.12.22 11:51, Ludwig Nussel wrote:
When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version.
is this then "%suse_version >= 1599"?
Yes, anything > 1500. Looks like 1550 is quite common.
I'd guess $HOWEVER_NEXT_ENTERPRISE_DISTRO_IS_NAMED 16 will also have usrmerge?
If it's based on Factory there's no way around that IMO. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
On Tue, 27 Dec 2022 11:51:19 +0100 Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Hi!
When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version.
So I propose to remove use of the %usrmerged macro in spec files. Of course spec files could manually set it based on %suse_version if that's convenient. Spec files just shouldn't rely on an externally set %usrmerged anymore.
Question: how will this affect future importing Tumbleweed packages into SLE15? darix -- Always remember: Never accept the world as it appears to be. Dare to see it for what it could be. The world can always use more heroes.
Marcus Rückert wrote:
On Tue, 27 Dec 2022 11:51:19 +0100 Ludwig Nussel <ludwig.nussel@suse.de> wrote:
When transitioning to usrmerged systemd we introduced the %usrmerged macro. Since there is no way back for Tumbleweed and already released distributions won't ever go for usrmerge, the macro is actually obsolete. It's sufficient to check for Tumbleweed which is usually done by checking %suse_version.
So I propose to remove use of the %usrmerged macro in spec files. Of course spec files could manually set it based on %suse_version if that's convenient. Spec files just shouldn't rely on an externally set %usrmerged anymore.
Question:
how will this affect future importing Tumbleweed packages into SLE15?
Not at all. SLE15 has no usrmerge and suse_version 1500 forever¹. cu Ludwig [1] https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macro... -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Ivo Totev HRB 36809 (AG Nürnberg)
On Mon, 2023-01-09 at 18:56 +0100, Ludwig Nussel wrote:
Marcus Rückert wrote:
Question:
how will this affect future importing Tumbleweed packages into SLE15?
Not at all. SLE15 has no usrmerge and suse_version 1500 forever¹.
I would like to suggest that we bump the suse_version of TW if we make fundamental changes to the distro architecture like this. It's not that we're lacking room in the version number space. We could use 1560 now, or even 1600. Obviously to late for the real breaking change (the usrmerge) now, but perhaps we could change this policy in the future. Martin
Am 09.01.23 um 20:53 schrieb Martin Wilck:
On Mon, 2023-01-09 at 18:56 +0100, Ludwig Nussel wrote:
Marcus Rückert wrote:
Question:
how will this affect future importing Tumbleweed packages into SLE15? Not at all. SLE15 has no usrmerge and suse_version 1500 forever¹. I would like to suggest that we bump the suse_version of TW if we make fundamental changes to the distro architecture like this. It's not that we're lacking room in the version number space. We could use 1560 now, or even 1600. Obviously to late for the real breaking change (the usrmerge) now, but perhaps we could change this policy in the future.
Martin
We're at 1599 already: https://build.opensuse.org/projects/openSUSE:Factory/prjconf Line 1497 Also: https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macro... Footnote 1: never rely on this version, it may change Change was made Dec 2 2021 https://en.opensuse.org/index.php?title=openSUSE:Packaging_for_Leap&diff=prev&oldid=161232
On Mon, 2023-01-09 at 21:11 +0100, Ben Greiner wrote:
We're at 1599 already: https://build.opensuse.org/projects/openSUSE:Factory/prjconf Line 1497
oops... sorry. But we don't have a number that separates "before usrmerge" and "after usrmerge", right? Martin
On 1/10/23 06:48, Martin Wilck wrote:
On Mon, 2023-01-09 at 21:11 +0100, Ben Greiner wrote:
We're at 1599 already: https://build.opensuse.org/projects/openSUSE:Factory/prjconf Line 1497
oops... sorry.
But we don't have a number that separates "before usrmerge" and "after usrmerge", right?
Martin
I guess if you really needed to know it for performing a migration you should have access to the VERSION in /etc/os-release during the %pre step and that should be enough to set up a Flag in a temp file to trigger that you also need to perform migration actions. Which isn't as clean as just reading an rpm macro but is still workable. -- 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
participants (6)
-
Ben Greiner -
Ludwig Nussel -
Marcus Rückert -
Martin Wilck -
Simon Lees -
Stefan Seyfried