On Fri, Aug 3, 2018 at 3:19 AM, Neal Gompa <ngompa13(a)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?