Fedora maintains both fedora-release and generic-release, the latter being made available mostly to assist Remixes with differentiating themselves. One major pain point is the need for Remixes to re-create the systemd presets that are part of fedora-release-common. It would be better if we could simply separate these out into a common fedora-presets package that any system-release providing package can import. If Remixes want to supplement these presets, they can still do so by providing additional files. The systemd preset drop directories handle this quite well simply by providing a lower-numbered filename. Reproducible: Always
Yeah, a fedora-systemd-presets package that ships these would be great. I wouldn't be opposed to doing this for F43, but let's try to get this into F44 first.
Yeah, I'm not sure how I feel about trying to do this for F43 post-Beta, but we can definitely land this for F44 in the near future. I'll try to carve out some time this week or next for it.
Actually, there's at least one question we need to answer: What should we do about the presets that apply only to specific Editions or Spins? If we're sharing the fedora-systemd-presets package with Remixes and such, I'm inclined to say that we should put only the common presets in this package and keep the per-Edition/Spin overrides in the fedora-release-identity-* packages. Or does anyone want to argue that we should have fedora-systemd-presets provide all the subpackages? I think that might just be more confusing than anything. It doesn't really help the Remixes if they want to add their own presets anyway.
> I'm inclined to say that we should put only the common presets in this package and keep the per-Edition/Spin overrides in the fedora-release-identity-* packages. Yes, I think so. generic-release-common has /usr/lib/systemd/system-preset/85-display-manager.preset /usr/lib/systemd/system-preset/90-default.preset /usr/lib/systemd/system-preset/99-default-disable.preset /usr/lib/systemd/user-preset/90-default-user.preset fedora-release-common has /usr/lib/systemd/system-preset/85-display-manager.preset /usr/lib/systemd/system-preset/90-default.preset /usr/lib/systemd/system-preset/99-default-disable.preset /usr/lib/systemd/user-preset/90-default-user.preset /usr/lib/systemd/user-preset/99-default-disable.preset (yes, the user presets in generic-release-common are completely broken). So just split the presets out into a subpackage and have generic-release-common require that...
(In reply to Stephen Gallagher from comment #3) > Actually, there's at least one question we need to answer: What should we do > about the presets that apply only to specific Editions or Spins? If we're > sharing the fedora-systemd-presets package with Remixes and such, I'm > inclined to say that we should put only the common presets in this package > and keep the per-Edition/Spin overrides in the fedora-release-identity-* > packages. > > Or does anyone want to argue that we should have fedora-systemd-presets > provide all the subpackages? I think that might just be more confusing than > anything. It doesn't really help the Remixes if they want to add their own > presets anyway. For now, let's leave them there. We should also move 81-desktop.preset to fedora-systemd-presets in a subpackage. For generic-release, we can ship an empty presets file with a comment inside the file to indicate what it exemplifies (to match in the ones with actual data in fedora-release subpackages for various fedora variants).
(In reply to Neal Gompa from comment #5) > (In reply to Stephen Gallagher from comment #3) > > Actually, there's at least one question we need to answer: What should we do > > about the presets that apply only to specific Editions or Spins? If we're > > sharing the fedora-systemd-presets package with Remixes and such, I'm > > inclined to say that we should put only the common presets in this package > > and keep the per-Edition/Spin overrides in the fedora-release-identity-* > > packages. > > > > Or does anyone want to argue that we should have fedora-systemd-presets > > provide all the subpackages? I think that might just be more confusing than > > anything. It doesn't really help the Remixes if they want to add their own > > presets anyway. > > For now, let's leave them there. We should also move 81-desktop.preset to > fedora-systemd-presets in a subpackage. Sorry, I can't parse "let's leave them there" cleanly. Could you rephrase it, please? I *think* you're agreeing with my proposal, but it's just ambiguous enough that I want to ask before assuming. > For generic-release, we can ship an empty presets file with a comment inside > the file to indicate what it exemplifies (to match in the ones with actual > data in fedora-release subpackages for various fedora variants). I'm a little lost after "ship an empty presets file" here. I think you're asking for a 80-remix.preset that contains no content, but a comment explaining that they can add `enable foo.unittype` or `disable bar.unittype` to override or supplement the default rules. Is that accurate?
(In reply to Stephen Gallagher from comment #6) > (In reply to Neal Gompa from comment #5) > > (In reply to Stephen Gallagher from comment #3) > > > Actually, there's at least one question we need to answer: What should we do > > > about the presets that apply only to specific Editions or Spins? If we're > > > sharing the fedora-systemd-presets package with Remixes and such, I'm > > > inclined to say that we should put only the common presets in this package > > > and keep the per-Edition/Spin overrides in the fedora-release-identity-* > > > packages. > > > > > > Or does anyone want to argue that we should have fedora-systemd-presets > > > provide all the subpackages? I think that might just be more confusing than > > > anything. It doesn't really help the Remixes if they want to add their own > > > presets anyway. > > > > For now, let's leave them there. We should also move 81-desktop.preset to > > fedora-systemd-presets in a subpackage. > > Sorry, I can't parse "let's leave them there" cleanly. Could you rephrase > it, please? I *think* you're agreeing with my proposal, but it's just > ambiguous enough that I want to ask before assuming. > > Leaving the variant-specific presets in fedora-release, but the generic 81-desktop.preset should move to fedora-systemd-presets. > > For generic-release, we can ship an empty presets file with a comment inside > > the file to indicate what it exemplifies (to match in the ones with actual > > data in fedora-release subpackages for various fedora variants). > > I'm a little lost after "ship an empty presets file" here. I think you're > asking for a 80-remix.preset that contains no content, but a comment > explaining that they can add `enable foo.unittype` or `disable bar.unittype` > to override or supplement the default rules. Is that accurate? "80-generic.preset", but yes.
I'm not sure this is all worth it. Couldn't we instead just add some docs on how you could take the existing fedora-release and rename/reuse it for your own distro? Instead of making another place we need to update things, adding to the dep chain and our of it we get... 5 presets that we don't have to sync between generic-release and fedora-release?
Well, there are other benefits. It means that any derivative doesn't need to fork the presets either. It also decouples the preset update from the Fedora release too (if we desire it).
I'm not sure I follow... right now they need to take fedora-release, change it to niftyos-release and adjust it to their needs. after this they will need to take fedora-release and fedora-presets and change both of them to their needs/name. It would allow changing presets without needing to update fedora-release, but... I don't see us updating these base presets all the time now?
Actually, no, they do not. Because systemd has a "first one wins" thing, you only need to ship overrides in your own package. So there's no need to change/fork fedora-systemd-presets at all.
Right, as Neal says, that's the whole point of this change: so that the makers of niftyos can have niftyos-release contain any changes from our default presets if they need them, but otherwise they just inherit ours and don't need to track them. Also, I just did a quick bit of analysis on the Fedora 42 fedora-release branch (starting at where it was forked from Rawhide): There have been 29 total commits in that span, 12 of which have modified one of the systemd presets. So they do see a fairly high rate of change, making it difficult for third-parties to keep up with.