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.
Thanks, Kamil
I'm somehow missing the point probably, but as a rawhide user, when I want to take some package from F28 (typically kernel), then I have to do "sudo dnf update --disablerepo=* --enablerepo=updates{,-testing} kernel* --release 28", i.e. the problem is that I have to enable the "updates" repositories and that is about organization of the packages, not about the 28 vs Rawhide. So how would your proposal help with this?
V.
Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
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.
Thanks, Kamil
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/...
On Wed, Aug 1, 2018 at 10:36 AM, Vít Ondruch vondruch@redhat.com wrote:
I'm somehow missing the point probably, but as a rawhide user, when I want to take some package from F28 (typically kernel), then I have to do "sudo dnf update --disablerepo=* --enablerepo=updates{,-testing} kernel* --release 28", i.e. the problem is that I have to enable the "updates" repositories and that is about organization of the packages, not about the 28 vs Rawhide. So how would your proposal help with this?
The current situation is that 'fedora', 'updates' and 'updates-testing' repos are disabled in Rawhide, and instead a single 'rawhide' repo is enabled (with hardcoded paths). It's true that if you specifically disable the rawhide repo and instead enable the fedora/updates/updates-testing ones (note: you're missing the fedora repo in your example), the command does work. But it's again one example of what you need to do differently on Rawhide than on other releases. I'd like to see the same approach wherever you are.
With the new approach, you could do simply this: $ dnf list/download/repoquery/whatever package --releasever=28 the same way as you do this on other releases.
Now, there are two ways how this can be handled by Fedora releng. Either they only enable the 'fedora' repo on Rawhide, and then if you wanted to access updates/updates-testing repos with this command line, you'd need to add --enablerepo=updates and/or --enablerepo=updates-testing. (You can say that this is still consistent with stable releases, it's just that the general expectation is that 'updates' repo is always enabled). Or they enable 'updates' repo by default on Rawhide as well (the same way stable releases have it), and they point it to an empty repo dir (they can even set it to never expire or almost never). In that case no --enablerepo will be necessary, and this will be 100% matching stable releases approach.
I admit the end-user benefit here is very small (except for consistency and perhaps documentation). When you start automating tasks and need to run such commands on different Fedora releases including Rawhide, the benefit might be larger.
Dne 1.8.2018 v 13:09 Kamil Paral napsal(a):
On Wed, Aug 1, 2018 at 10:36 AM, Vít Ondruch <vondruch@redhat.com mailto:vondruch@redhat.com> wrote:
I'm somehow missing the point probably, but as a rawhide user, when I want to take some package from F28 (typically kernel), then I have to do "sudo dnf update --disablerepo=* --enablerepo=updates{,-testing} kernel\* --release 28", i.e. the problem is that I have to enable the "updates" repositories and that is about organization of the packages, not about the 28 vs Rawhide. So how would your proposal help with this?The current situation is that 'fedora', 'updates' and 'updates-testing' repos are disabled in Rawhide, and instead a single 'rawhide' repo is enabled (with hardcoded paths). It's true that if you specifically disable the rawhide repo and instead enable the fedora/updates/updates-testing ones (note: you're missing the fedora repo in your example)
Obviously I am not enabling "fedora" repo, because it is too old. But now I see what you are talking about. I should have enabled "fedora" repo all the time and it should work the same way for f28 as for the rawhide. This would make the life easier indeed.
V.
, the command does work. But it's again one example of what you need to do differently on Rawhide than on other releases. I'd like to see the same approach wherever you are.
With the new approach, you could do simply this: $ dnf list/download/repoquery/whatever package --releasever=28 the same way as you do this on other releases.
Now, there are two ways how this can be handled by Fedora releng. Either they only enable the 'fedora' repo on Rawhide, and then if you wanted to access updates/updates-testing repos with this command line, you'd need to add --enablerepo=updates and/or --enablerepo=updates-testing. (You can say that this is still consistent with stable releases, it's just that the general expectation is that 'updates' repo is always enabled). Or they enable 'updates' repo by default on Rawhide as well (the same way stable releases have it), and they point it to an empty repo dir (they can even set it to never expire or almost never). In that case no --enablerepo will be necessary, and this will be 100% matching stable releases approach.
I admit the end-user benefit here is very small (except for consistency and perhaps documentation). When you start automating tasks and need to run such commands on different Fedora releases including Rawhide, the benefit might be larger.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/...
Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
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.
Just note that fedora-rawhide.repo has: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on x86_64 machine).
So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64 and updated on every branching or symlink need to be provided.
Miroslav
On Thu, Aug 2, 2018 at 12:23 PM, Miroslav Suchý msuchy@redhat.com wrote:
Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
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.
Just note that fedora-rawhide.repo has: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on x86_64 machine).
So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64 and updated on every branching or symlink need to be provided.
Interesting, this is something Kevin mentioned during the releng meeting, which I didn't completely get:
17:09:15 <nirik> also would fix a long standing issue around moving to rawhide from a stable relase and gpg key...17:09:35 <nirik> because the gpg key file is called 'whatever-rawhide' not 'whatever-29'
It seems he was mistaken then?
But yes, the files would have to be renamed, thanks for a reminder.
On 08/03/2018 02:11 AM, Kamil Paral wrote:
On Thu, Aug 2, 2018 at 12:23 PM, Miroslav Suchý msuchy@redhat.com wrote:
Dne 31.7.2018 v 15:04 Kamil Paral napsal(a):
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.
Just note that fedora-rawhide.repo has: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on x86_64 machine).
So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64 and updated on every branching or symlink need to be provided.
Interesting, this is something Kevin mentioned during the releng meeting, which I didn't completely get:
17:09:15 <nirik> also would fix a long standing issue around moving to rawhide from a stable relase and gpg key...17:09:35 <nirik> because the gpg key file is called 'whatever-rawhide' not 'whatever-29'
It seems he was mistaken then?
But yes, the files would have to be renamed, thanks for a reminder.
Yeah, we finally did change it... for a long time it was rawhide which confused people who passed the number.
Likely here we want a link from "rawhide" to the current number and change that at each branching.
kevin
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.
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.
On Thu, Aug 2, 2018 at 2:07 PM Neal Gompa ngompa13@gmail.com wrote:
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.
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-leave@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/...
On 08/02/2018 05:04 AM, Neal Gompa wrote:
This might surprise you, but I actually prefer the current way. It makes activating Rawhide an explicit action that can stay carried forward.
The same for the proposed change, once you install fedora-release from rawhide you are on rawhide until and unless you intentionally switch.
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.
I've been looking into this the last week or so by chance. Rawhide does compose containers every day with rawhide compose, they are just not correctly uploading to our registry. Hopefully this will be fixed soon.
I don't think the answer to something being old or broken is to sigh and wander off. We need to fix those things, and I think we are making progress on doing so.
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.
I'm not sure I follow here... you don't think we should make rawhide something to rely on because we have regular releases?
In any case I think rawhide is very useful and without it our stable releases would be vastly more diffcult. We can definitely do better to make it stable, but I think it's quite usable.
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.
The number will keep working too. We can make that an alias in mirrormanager. So, for example if we had this implemented now and we branched 29 off, '29' would point to the branched release, '30' or 'rawhide' would point to rawhide. If you installed fedora-release from rawhide it would keep you on rawhide, if you install from branched or distro-sync to the branched fedora-release (by doing a 'dnf --releasever=29 distro-sync fedora-release') you go on branched. This means you don't need to worry about fedora-release-rawhide and enabling/disabling repos, and makes everyone's life easier.
kevin
On Thu, Aug 2, 2018 at 7:12 PM Kevin Fenzi kevin@scrye.com wrote:
On 08/02/2018 05:04 AM, Neal Gompa wrote:
This might surprise you, but I actually prefer the current way. It makes activating Rawhide an explicit action that can stay carried forward.
The same for the proposed change, once you install fedora-release from rawhide you are on rawhide until and unless you intentionally switch.
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.
I've been looking into this the last week or so by chance. Rawhide does compose containers every day with rawhide compose, they are just not correctly uploading to our registry. Hopefully this will be fixed soon.
I don't think the answer to something being old or broken is to sigh and wander off. We need to fix those things, and I think we are making progress on doing so.
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.
I'm not sure I follow here... you don't think we should make rawhide something to rely on because we have regular releases?
I'm saying that if we try to pull off something similar to openSUSE Tumbleweed with our current infrastructure and tooling, upstreams like GCC and glibc could no longer leverage our Rawhide to validate their code.
In any case I think rawhide is very useful and without it our stable releases would be vastly more diffcult. We can definitely do better to make it stable, but I think it's quite usable.
It's not usable whenever we have compiler transitions or add more weird GCC plugins, and that's something I've accepted will never change as long as we're the distribution that helps make GCC great. And that's fine.
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.
The number will keep working too. We can make that an alias in mirrormanager. So, for example if we had this implemented now and we branched 29 off, '29' would point to the branched release, '30' or 'rawhide' would point to rawhide. If you installed fedora-release from rawhide it would keep you on rawhide, if you install from branched or distro-sync to the branched fedora-release (by doing a 'dnf --releasever=29 distro-sync fedora-release') you go on branched. This means you don't need to worry about fedora-release-rawhide and enabling/disabling repos, and makes everyone's life easier.
But the problem is that it does make things slightly harder. 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. 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.
And how do you propose people sync down from Rawhide to "branched"? Or sync up from an old Rawhide to "branched"/"stable" which this change? From what I can tell, that wouldn't be easy.
-- 真実はいつも一つ！/ Always, there's only one truth!
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?
On Fri, Aug 3, 2018 at 12:24 AM, Kevin Fenzi kevin@scrye.com wrote:
I just don't think it's smart to drop the release number thing and the fedora-repos-rawhide package.
The number will keep working too. We can make that an alias in mirrormanager. So, for example if we had this implemented now and we branched 29 off, '29' would point to the branched release, '30' or 'rawhide' would point to rawhide.
To be fair here, if COPR and other third party inherited the "single repo for all releases, using $releasever" approach as suggested, the number would work for internal Fedora repos (because it's easy to do so in mirrormanager), but it wouldn't work for COPR and other third-party repos (because they don't have a mirrormanager). Of course they could make it work by maintaining symlinks, just as now they can make it work by maintaining symlink - but they don't.
The question is what is the important use case for using a number in repo network requests, if we make it work by default (using releasever=rawhide). Would anyone need to side-step dnf to perform their own calls, and this would complicate the life for them? I don't know, tell me. (We could make the releasever value easily obtainable in that case, either through dnf or through evaluating an rpm macro).
On Thu, Aug 2, 2018 at 2:04 PM, Neal Gompa ngompa13@gmail.com wrote:
This might surprise you, but I actually prefer the current way. It makes activating Rawhide an explicit action that can stay carried forward.
It's going to stay explicit and persistent, as explained by Kevin.
This change makes no sense unless we were actually going to make Rawhide something that people could rely on.
I'm not sure if you're aware, but that's exactly what many people are attempting to do. There are plans for automated gating in Rawhide. And since I was one of those who were at least partially involved in this, I proposed this change so that life is easier whenever you try to automate stuff across releases, including Rawhide. I'm not saying it's a silver bullet, and I hope I haven't missed any important use cases (hence this discussion), but it should be one step closer to more consistency across releases, therefore easier operation and automation.
-
Kamil Paral -
Kevin Fenzi -
Michal Novotny -
Miroslav Suchý -
Neal Gompa -
Vít Ondruch