Bug 1029775 - systemd-presets-branding: Versioning inconsistency between openSUSE and SLE
systemd-presets-branding: Versioning inconsistency between openSUSE and SLE
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Ludwig Nussel
E-mail List
:
Depends on:
Blocks: 1012850
  Show dependency treegraph
 
Reported: 2017-03-16 18:51 UTC by Stanislav Brabec
Modified: 2020-06-30 10:23 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stanislav Brabec 2017-03-16 18:51:30 UTC
While creating unified util-linux.spec that can be used for Tumbleweed, Leap and SLE, I found a versioning problem that makes impossible to require or conflict correct version of systemd-presets-branding symbol:

systemd-presets-branding-SLE has version 12.1 in SLE 12 SP3.

systemd-presets-branding-openSUSE has version 0.3 in Leap 42.3.

systemd-presets-branding-openSUSE has version 0.4 in Tumbleweed.

All three packages export symbol
systemd-presets-branding = %{version}

This versioning is not usable.

Now I am going to add uuidd to both Leap and SLE. It requires version increment for branding package and conflict in util-linux package.

We have to make branding versioning consistent between SLE and openSUSE.

And we have to use numbers > 12.1.

Maybe all branding packages should use:
Version: %{suse_version}
or
Version: %{suse_version}.1

From systemd-presets-branding-SLE:

Wed Feb 12 16:35:33 UTC 2014 - meissner@suse.com
- bump version to match product

This versioning change was never done in systemd-presets-branding-SLE.
Comment 1 Stanislav Brabec 2017-03-16 19:42:30 UTC
In my particular case, move of uuidd to systemd-presets-branding, I could use:
Conflicts: systemd-presets-branding-SLE < 1315

SLE12 SP3: systemd-presets-branding-SLE-1315
Leap 42.3: systemd-presets-branding-openSUSE-1315
openSUSE Tumbleweed: systemd-presets-branding-openSUSE-1330

But next time we will need a similar version dependency, %{suse_version} scheme will not help, because Tumbleweed would require <= 1330, but SP3/Leap 42.3 <= 1315.

=> This versioning scheme does not look wise.


Probably perform one time bump to version 13 (or 12.3) for all branding packages.

And starting with that, synchronize versions across all branding names.
Comment 2 Ludwig Nussel 2017-03-17 09:00:53 UTC
Why is the conflict needed? I thought the branding-preset-states tool is meant to apply presets no matter whether the package is installed first or later?
Comment 3 Stanislav Brabec 2017-03-17 14:36:08 UTC
Well, with the new branding-preset-states, conflict is no more needed for each new service introduced. But versioning is still required, especially for online updates, as correct work of package depends on new version of preset.

And for special case of preset migration, conflict is really needed.

I think, that the easiest what we can do, is setting all Tumbleweed, SLE12 SP3, Leap 42.3 either to 12.1.1 or 12.2 or 12.3 or 13, so util-linux upgrade will go correctly.

Later, we always have to keep Leap and SLE branding packages in sync to make possible Requires: in packages that does not need %if %{is_opensuse}.


But for migration of preset from one file to another, it is important.

Imagine that the order is not correct:


A) Migration of preset file from one package to another, wrong order:

step 1: Preset disappears from the old file.

branding-preset-states detect that and force disables it

step 2: Preset appears in the new file.

branding-preset-states detect that and force enables it

=> After upgrade that did not change preset value, the service is force-enabled.


It is wrong. In correct order, we get:

step 1: Preset appears in the new file.

branding-preset-states detect no active change

step 2: Preset disappears from the old file.

branding-preset-states detect no active change

=> No force preset is performed, service is kept in previous state.


B) Introduction of new service with new preset

Wrong order:

step 1: New service is installed.

Standard %service_add_post calls preset, and preset and sets its initial state to disabled.

step 2: Preset appears in the new version of branding.

branding-preset-states detect that and force enables it

=> Service is broken until correct version of presets is installed. Small pain of two calls of preset instead one is acceptable. => Requires is required, but Conflicts is better.


Correct order:

step 1: Preset appears in the new version of branding.

no service of such name => no task for branding-preset-states

step 2: New service is installed.

Standard %service_add_post calls preset, and preset and sets its initial state to enabled.

=> Perfect!



Fri Feb 10 09:46:22 UTC 2017 - fbui@suse.com

- Enable by default uuidd shipped by util-linux (bsc#1012850)

  util-linux was previously shipping a preset file enabling uuidd by
  default. This is now done here as other packages are not supposed to
  ship their own preset rules.

  Also increase the package version so util-linux can conflict with
  the previous versions and hence will be updated *after* the new
  version of the presets package is. This is important otherwise if
  util-linux removed its preset file first, then the presets package
  would believe a new change in the presets and you enable again
  uuidd.
Comment 4 Ludwig Nussel 2017-03-17 14:52:06 UTC
Ideally the presets package should come from Factory in 42.3 so the package version would be the same as in Factory (e.g 84.87). There should be no migration of presets from one package to the other in the first place as packages are not meant to ship presets. Maybe we need to introduce an rpmlint check to enforce that. util-linux is a rather special case here IMO.

What would be the worst that could happen without the conflicts here? An installed uuidd that the admin disabled would be re-enabled again. In my naiveness I'd say I can live with that since uuidd is not installed by default.
Comment 5 Stanislav Brabec 2017-03-17 15:21:53 UTC
Force activation of uuidd is relatively minor issue, but something that should not happen.


Yes, Factory could have the same package as Leap 42.3, as long as we don't intentionally decide to diverge.

SLE has a different package, but version should be the same.

Having SLE and Leap in sync is important, so we could use:

systemd-presets-branding-*:
Add preset
enable foo.service
and increase version from n to n+1

package foo:
Conflicts: systemd-presets-branding < n+1
or
Requires: systemd-presets-branding >= n


If we not sync, we have to use:

package foo:
%if 0%{?is_opensuse}
Conflicts: systemd-presets-branding-openSUSE < n+1
%else
Conflicts: systemd-presets-branding-SLE < s+1
%endif

or

%if 0%{?is_opensuse}
Requires: systemd-presets-branding-openSUSE >= n
%else
Requires: systemd-presets-branding-SLE >= s
%endif
Comment 6 Stanislav Brabec 2017-03-17 16:12:33 UTC
Submitted:
http://build.opensuse.org/request/show/480879

I will submit util-linux with this version dependency to Factory.

It could be accepted to Leap 42.3 and SLE 12 SP3 as well.
Comment 8 Bernhard Wiedemann 2017-03-20 07:00:31 UTC
This is an autogenerated message for OBS integration:
This bug (1029775) was mentioned in
https://build.opensuse.org/request/show/481214 Factory / systemd-presets-branding-openSUSE
Comment 9 Bernhard Wiedemann 2017-03-21 13:00:41 UTC
This is an autogenerated message for OBS integration:
This bug (1029775) was mentioned in
https://build.opensuse.org/request/show/481768 Factory / systemd-presets-branding-openSUSE
Comment 10 Thorsten Kukuk 2017-05-02 10:58:31 UTC
This change broke CaaSP/Kubic.

If you make changes/new requires to systemd-presets-branding packages, you should adjust at least ALL packages in FACTORY!
Comment 11 Bernhard Wiedemann 2017-05-02 12:00:38 UTC
This is an autogenerated message for OBS integration:
This bug (1029775) was mentioned in
https://build.opensuse.org/request/show/492447 Factory / systemd-presets-branding-CAASP
Comment 13 Stanislav Brabec 2020-06-30 10:23:34 UTC
It was fixed long time ago.