And at the same time fedora-release now gained /lib/systemd/system-preset/90-default.preset (by moving it from systemd package) which contains default presets for systemd services. We added this dependency in lvm2 on fedora-release in recent build so we're sure that new lvm2 service (lvm2-lvmpolld.{socket,service}) is enabled by default (bug #1222495). The generic-release does not have this preset file so it's not usable for the purpose we need.

Does this mean that currently we can't add a dependency in the generic release for the systemd preset we need? This was possible while the preset file was in systemd package, so from this point of view, we have a regression caused by moving the preset file to fedora-release package? Should it be copied into generic-release too?

It is possible to add the preset file to generic-release. With fedora-release getting more complicated it might make more sense to fold generic-release into fedora-release and treat it more like a product. But that isn't likely to happen in the short term.

I am not sure why you have to guaranty that if lvm2 is installed it needs to be enabled by default. I can see wanting to have anaconda installed without wanting to use lvm.

Isn't it also possible to have lvm2 have its own preset file or is that contrary to how preset values are supposed to be handled?

(In reply to Bruno Wolff III from comment #2)
> I am not sure why you have to guaranty that if lvm2 is installed it needs to
> be enabled by default. I can see wanting to have anaconda installed without
> wanting to use lvm.
> 

Nope, this is not about having whole lvm2 installed and enabled by default. It's just about making sure that IF lvm2 is installed, then some of its services should be enabled by default for it to work correctly. In case of lvm2, nothing extraordinary happens if those services are not prepared, but lvm2 may emit some warnings (while doing fallback to functionality without these services).

> Isn't it also possible to have lvm2 have its own preset file or is that
> contrary to how preset values are supposed to be handled?

I'm counting with the fact that 90-default.preset file is the one used for the whole distribution and services which should be enabled by default should be registered there. Or any other file in the /lib/systemd/system-preset directory, but that one is possesed by systemd (or fedora-release package in newer versions as it's being moved from systemd to fedora-release at the moment).

If I could install my own preset file into /lib/systemd/system-preset, I'd be fine with that. But I'm not sure if this is what the design was - then any package could enable any service by default at will in the distribution, which is not quite correct.

I think we need fedora-release subpackage that is available everywhere and which includes this 90-default.preset file so we can add proper dependency if needed in other packages to be sure that certain services are enabled by default.

I've heard that this was considered by Fesco already. Dennis, would it be possible to introduce such subpackage?

sub-package is not the right thing. we need to duplicate the presets or we need to make the presets be there own package. I am going to duplicate the presets into generic-release. realistically someone doing a remix should fork generic-release and set their own presets

Dennis has now made the above change and the update generic-release is currently available in rawhide.

(In reply to Dennis Gilmore from comment #5)
> sub-package is not the right thing. we need to duplicate the presets or we
> need to make the presets be there own package. I am going to duplicate the
> presets into generic-release. 

Which means we can't do any hard dependency on concrete package ("Requires: generic-release >= ..." or "Requires: fedora-release >= ..." - if I put both of them, one will always fail). So I think we really need own package for the presets.

Proposed as a Blocker for 23-final by Fedora user bruno using the blocker tracking app because:

  Release identification

A Package-x-generic-16.pngfedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images and the appropriately versioned Package-x-generic-16.pnggeneric-release package must be available in the release repository. 
Note the issue here is that generic-release can not currently be installed allong with lvm2 (and hence anaconda) which would block the compose of live images that use generic-release and are meant to be installable. This may be to far from the literal rule to still count as a blocker, but it does seem to fit the spirit of the rule.

"realistically someone doing a remix should fork generic-release and set their own presets"

I disagree. Many / most remixes wouldn't have any particular reason to change the presets. Just because you're doing something to Fedora which falls outside the 'spins' rules doesn't seem to me to imply at all that you want different service defaults for some reason.

"Which means we can't do any hard dependency on concrete package ("Requires: generic-release >= ..." or "Requires: fedora-release >= ..." - if I put both of them, one will always fail). So I think we really need own package for the presets."

You can depend on 'system-release', which is provided by both fedora-release and generic-release (and which remixes are expected to have their own foo-release package provide).

Discussed at 2015-07-13 F23 blocker review meeting: http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-07-13/f23-blocker-review.2015-07-13-16.03.log.txt . For now, this is rejected as a blocker, as the only relevant criterion requires only that a generic-release package be present - it doesn't actually require that it be possible to build images with it, or that they work. Bruno is going to kick off a discussion about possible adjustments to the criteria on some relevant lists; if we do agree to extend the requirements for generic-release , it may make sense to re-propose this as a blocker later.

(In reply to Adam Williamson from comment #9)
> You can depend on 'system-release', which is provided by both fedora-release
> and generic-release (and which remixes are expected to have their own
> foo-release package provide).

But there's only:

  "Provides:       system-release(%{version})"

...where %version is the Fedora version (currently 23). But there's no minor version number to depend on where the preset got changed exactly (for example, in case of fedora-release, it gained the proper preset in version 23-0.13). This doens't matter for full release of Fedora probably, but in rawhide it makes a difference as that one is rolling.

Anyway, for now, I'll change the dependecy to "Requires: system-release >= 23". But that's not quite complete for rawhide as it still allows me to install lvm2 with an older preset file without the changes we need... But I don't want to block lvm2 + anaconda and other stuff in rawhide because of this... so I'm giving up.

I just wanted to point here that there is clear regression - when the preset file was in systemd package, we could do a proper dependency on fresh preset file which includes changes needed (dependency on exact systemd version). With the move of preset files to *-release, I can't find a way how to do such dependency properly and working for all possible environments.

Both fedora-release and generic-release provide unversioned "system-release":

[adamw@adam gtk3 (master %)]$ rpm -q --provides fedora-release
...
system-release
...
[adamw@adam gtk3 (master %)]$ sudo dnf-3 repoquery --provides generic-release
...
system-release

(In reply to Adam Williamson from comment #12)
> Both fedora-release and generic-release provide unversioned "system-release":

...exactly, which is not perfect to check for exact version where concrete preset file appeared (or where the content changed so that we can rely on that).

clearing needinfo