Comment # 3 on bug 1029775 from Stanislav Brabec

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.