On Wed, Mar 11, 2020 at 10:26 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2020-03-10 at 13:21 -0600, Chris Murphy wrote: > > Retrying while simplifying... > > > > The spec file contains these two lines: > > > > %triggerpostun -- fedora-release < 32 > > %systemd_post fstrim.timer > > > > I don't know the proper terminology, but I think 'fedora-release' is a > > meta package? Since this doesn't exist on anyone's F31 system, I > > wonder if this should be 'fedora-release-common' instead? > > hmm, that's actually a bit tricky, because there's no 'right' way to > use a real package there. It's canon that you can't assume the 'fedora- > release' packages specifically are installed, because we allow for > customization: the 'system-release' virtual provides exist for this > purpose. All the 'fedora-release' and 'generic-release' subpackages > should provide the same 'system-release' stuff, anything that depends > on release-y things is supposed to use 'system-release' (not 'fedora- > release'), and the idea is that if you're branding Fedora, you fork > generic-release into your *own* 'branded' -release packages which > should also provide all the canonical 'system-release' provides. > > So...if you can't use virtual provides for triggers, it looks hard to > do that :/ It sounds like Editions definitely have 'fedora-release-common' (and probably spins created by Fedora). Right? So that means this trigger needs to be 'fedora-release-common' to have some chance of affecting upgrades; where 'fedora-release' definitely won't work. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx