On Tue, Sep 09, 2025 at 04:23:43PM +0200, Neal Gompa wrote: > On Tue, Sep 9, 2025 at 4:21 PM Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > > > On Tue, Sep 09, 2025 at 04:07:43PM +0200, Miro Hrončok wrote: > > > On 09. 09. 25 16:03, Zbigniew Jędrzejewski-Szmek wrote: > > > > generic-release is FTI > > > > > > This happens after each branching. I fixed that in the past, but at a > > > point > > > I decided not to care: there were no users screaming, CI systems > > > breaking... > > > > It is referenced in > > https://build.opensuse.org/projects/Fedora:Rawhide/prjconf. > > I got pinged that it apparently broke some automated builds of systemd. > > What was the original raison d'être for the package? The description says > > > > > This package explicitly is a replacement for the trademarked release > > > package, if you are unable for any reason to abide by the trademark > > > restrictions on that release package. > > > > but fedora-release-common is mostly a normal package. The only file > > that could be relevant is > > /usr/share/licenses/fedora-release-common/Fedora-Legal-README.txt: > > > > > The Fedora Operating System is a compilation of software packages, > > > each under its own license. The compilation itself is released under > > > the MIT license (see the file LICENSE). However, this compilation > > > license does not supersede the licenses of code and content > > > contained in the Fedora Operating System, which conform to the legal > > > guidelines described at > > > https://docs.fedoraproject.org/en-US/legal/license-approval/ > > > > This doesn't say anything about copyright. It just says that Fedora > > the OS is licensed under some license, which is a fairly generic > > statement. I don't see a problem with that file being present > > in a package, when the package is used to build something other > > than one of the official Fedora editions or spins. The problem > > would only be if that thing was labeled as "Fedora", but that's > > a completely separate issue. > > > > The maintainance effort of keeping presets updated in generic-release > > is non-trivial… I think we should retire generic-release and just > > tell people to use fedora-release-common. > > > > We maintain generic-release as a way for people to fork to build their > own branding, just like we do with generic-logos. I would prefer not > to lose them. > > What we could do is subpackage all the presets out and have both > generic-release and fedora-release depend on them.
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? Zbyszek P.S. I found this now in generic-release/README.license: > This document provides information about where we are right now and where I'd > like to go. Eventually there will be information about how to make tarball > releases and update the generic-release packages. > > Currently I have just imported the (extracted) tarball from fedora 20. We > currently don't have a build for rawhide with a version of 21. This is > the top priority. > fedora-release has some features that would be nice to get into > generic-release, in particular the arch mapping that associates the > correct keys for different architecures. > > The package version needs to match the fedora release (unless we switch > over to just relying on the system-release(release) provides, but that > seems to be premature now), but I'd like to allow multiple tarballs > for a single release (to add features or keys) with different versions. > My thought on this was to use a major.minor version, where major is the > fedora release version and would be used for the package version. Minor > would just end up in the package release. > > I don't want to build new tarballs to cover spec file changes that are > just configuration or changelog updates. I prefer to not keep changelog > updates in this repo, as changes to the spec file will be documented > in git. When changes are incorporated into packages, important notes > from the git log, can be added to the changelog. > > While there is currently just a master branch, the plan is to add a new > branch each time Fedora is branched. I don't think we'll go back and > add branches before f21. -- _______________________________________________ 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
