http://bugzilla.suse.com/show_bug.cgi?id=1029775 http://bugzilla.suse.com/show_bug.cgi?id=1029775#c1 --- Comment #1 from Stanislav Brabec <sbrabec@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1029775 http://bugzilla.suse.com/show_bug.cgi?id=1029775#c3 --- Comment #3 from Stanislav Brabec <sbrabec@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1029775 http://bugzilla.suse.com/show_bug.cgi?id=1029775#c5 --- Comment #5 from Stanislav Brabec <sbrabec@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1029775 http://bugzilla.suse.com/show_bug.cgi?id=1029775#c8 --- Comment #8 from Bernhard Wiedemann <bwiedemann@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1029775 http://bugzilla.suse.com/show_bug.cgi?id=1029775#c10 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com --- Comment #10 from Thorsten Kukuk <kukuk@suse.com> --- 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! -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1029775 https://bugzilla.suse.com/show_bug.cgi?id=1029775#c13 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #13 from Stanislav Brabec <sbrabec@suse.com> --- It was fixed long time ago. -- You are receiving this mail because: You are on the CC list for the bug.