On Tue, Sep 9, 2025 at 3:52 PM Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > On Tue, Sep 09, 2025 at 09:27:54PM +0200, Neal Gompa wrote: > > On Tue, Sep 9, 2025 at 7:35 PM Stephen Smoogen <ssmoo...@redhat.com> wrote: > > > > > > > > > > > > On Tue, 9 Sept 2025 at 13:04, Adam Williamson > > > <adamw...@fedoraproject.org> wrote: > > >> > > >> On Tue, 2025-09-09 at 14:46 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > >> > Could we instead make all that part of fedora-release? generic-release > > >> > is mostly a clone of fedora-release, with a lot of outdated stuff. > > >> > What would be required to use one of the subpackages of fedora-release > > >> > (possibly a new subpackage) and retire generic-release? > > >> > > >> I think the problem with that is that then any forks would need to > > >> include the fedora-release source RPM, and the goal of generic-release > > >> (and the overall concept of having multiple providers of system-release > > >> and system-logos) is to make that not necessary. > > > > > > > > > Would it make sense to change the way the src.rpms are built and with > > > generic-release being the 'parent' of fedora-release so that system-wide > > > changes happen in both that way. Maybe something like a parent 'project' > > > which has a template set of jinja (or whatever the cool one is these > > > days) and then changes get made, a make is made, and several src tar > > > balls are generated which can each be their own package versus a > > > sub-package. > > > > > > Does that make sense? > > > > Please no. The fedora-release package is already insanely complex, we > > shouldn't make it worse. The generic-release package is intended to be > > simple for the purpose of being replacement branding. > > OK. It seems that my idea of getting rid of generic-release is not > going to fly. I merge the PR that was waiting for the last 7 months > and updated generic-release for 44 to fix the FTI and pushed builds > to F43 and rawhide. > > > To be honest, I've wondered for a while if we should just pull out the > > presets and have a systemd-presets package instead that contains these > > things so that fedora-release and generic-release don't need duplicate > > preset files and can just depend on the presets packages. That way, > > the presets can also be inherited into ELN and CentOS/RHEL trivially > > too. > > I think that'd make sense. Probably better to call it fedora-presets > to maintain visual seperation from systemd subpackages. >
I'm pretty sure we three had this same conversation a couple of Flock conferences ago, all agreed this was the right approach, and then none of us got around to actually doing it. I've just opened https://bugzilla.redhat.com/show_bug.cgi?id=2394231 to track it. I think we can get this into Rawhide for F44. I'm on the fence about whether we want to try and do this in Fedora 43, post-Beta. Comments welcome. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
