On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral <kparal@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.