On Thu, Aug 2, 2018 at 2:07 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral <kpa...@redhat.com> wrote: > > > > Hello devel list, > > > > this is a request for comments for a recent proposal I filed at releng > tracker: > > https://pagure.io/releng/issue/7445 > > > > In short, package managers on Rawhide would no longer replace > $releasever variable with a numerical value (like '29' at this moment, soon > '30'), but with 'rawhide' string instead. I hope this change will make life > a bit easier for third-party repos maintainers, for users, for developers > and sysadmins, and for release engineering. The technical implementation > can be seen in the ticket (it's the 'Proposed solution 1'), together with a > long discussion. > > > > To provide a longer explanation of the improvements I expect this to > bring: > > * Third-party repo maintainers will no longer need to provide two > different repo files, one for stable Fedora releases using $releasever in > URLs, and one for Rawhide hardcoding 'rawhide/' in URL and avoiding > $releasever in URL. (Technically, two repo files are not needed if you > always use a numbered dir even for Rawhide, but that's maintenance-heavy, > because you need to change the directory number precisely at Branching > time). This involves COPR as well. > > * Users will be able to run commands like "dnf ... --releasever=28" even > on Rawhide. That doesn't work at the moment, because most repo files don't > use $releasever and instead have 'rawhide/' hardcoded. > > * Developers and sysadmins will be able to use the same approach > regarding repositories for stable Fedora releases and Rawhide. Rawhide will > no longer be different, requiring special treatment. For example, the same > repo URL can be used to install a system, or the same URL can be used to > add an additional repository to an existing system. As an engineer working > on automation, I was always annoyed how I need to special-case Rawhide > everywhere (and of course, maintain a config file that states which release > number Rawhide currently maps to). That will hopefully be no longer > necessary, or very much reduced. > > * Fedora release engineers should be able to get rid of > fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the > standard repo files instead (making use of $releasever). > > > > There might be other advantages, which I haven't tested or though of. > > > > There are also disadvantages. The only one I know of at this moment, is > that PackageKit is currently incompatible with this change (it uses custom > logic for populating $releasever, different from dnf logic) and will need > adjustments. > > > > Fedora releng has pre-approved this change in the ticket, and the point > of this email is to ask for more feedback from all of you. I'd appreciate > if you could help us identify edge cases we haven't thought of, or point > out which tools would be incompatible with this change, so that we can > track them and discuss it with their developers. > > > > This might surprise you, but I actually prefer the current way. It > makes activating Rawhide an explicit action that can stay carried > forward. The other thing is, realistically, few third party folks try > to build for Rawhide because Rawhide snapshots are either too old or > too broken. > > Case in point, the Docker containers for Rawhide effectively look like > Fedora 28, so what's the point? And upgrading to the latest released > compose just breaks everything, so it's not useful there either. > > This change makes no sense unless we were actually going to make > Rawhide something that people could rely on. And I'm not sure that's a > good idea, since we have a nice cadence of releasing every 6 > months(-ish). It's already too hard to keep Rawhide working because of > GCC breakages and the DNF stack work, and upstreams rely on our > Rawhide tree to suss out these kinds of things. > If we can make rawhide something that people can rely on, the actual releases will benefit from it as well. > > And I would argue that special casing Rawhide is sort of the point, > but I have no objection to making dnf --releasever=rawhide distro-sync > also work. I just don't think it's smart to drop the release number > thing and the fedora-repos-rawhide package. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XGMTZTWR2QYDNSCONEPS4RR567DELMDT/ >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VN5CCM2KQDMSYBSHBLOO3X624WZ5VBBO/
