On Fri, Aug 3, 2018 at 3:19 AM, Neal Gompa <ngompa13@gmail.com> wrote:
And
you're not quite correct about this. The way that DNF gets this value
is through identifying the package that provides "system-release" or
"distribution-release" and identifies the version set for the package.
That version is what propagates to set $releasever.

Not quite. I have tested the patch in "Proposed solution 1" in the releng ticket and it works. The code is here:
https://github.com/rpm-software-management/dnf/blob/6517f47c94bdf2da2b1ce11605babee4d8cb8756/dnf/rpm/__init__.py#L29

If you set
system-release(releasever) = value
then 'value' is used instead of identifying the package version.

If you see a logical mistake somewhere, please tell me. But in my testing dnf correctly used 'value' (i.e. 'rawhide') with this patch.
 
Hilariously,
PackageKit independently reads VERSION_ID from os-release(5) to
determine this. These don't always agree. And in addition, it's
impossible to stay on Rawhide through PackageKit without the controls
through fedora-repos-rawhide forcing it.

Yes, that's mentioned in the ticket and in the introductory email here. I'll need to ask PackageKit developers to use the DNF logic instead of using a custom one. This is actually already "broken" - having two package managers, each detecting releasever in a different manner - it just has never been a problem in Fedora, because they've both arrived at the same answer so far.
 

And how do you propose people sync down from Rawhide to "branched"?

Again, it's in the ticket. Why wouldn't this work? (Once Branched == F29 and Rawhide == F30)

sudo dnf distrosync fedora-release\* --releasever=29

 
Or
sync up from an old Rawhide to "branched"/"stable" which this change?
From what I can tell, that wouldn't be easy.

It should work with the same command as above, shouldn't it?