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
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 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
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
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...
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...
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%C2%A0Line 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%C2%A0Line 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.
-
Ben Greiner -
Ludwig Nussel -
Marcus Rückert -
Martin Wilck -
Simon Lees -
Stefan Seyfried