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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/
_______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/XUJUEHMKDFAYZCBNK6BRY72ZNQ4EHWAE/
