On Fri, Jun 21, 2019 at 5:47 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Fri, 2019-06-21 at 13:28 +0200, Adam Samalik wrote:
> To keep the expectations of Fedora's stable ABI within a release, we can't
> change the default stream of a module mind-release. I know, that's probably
> clear and that's not the issue here. But building on that, at the same
> time, we can't let "dnf update" to change streams on your system
> mid-release, because that would be basically breaking the ABI expectations
> as well — different mechanics, same problem.
OK, so, this is one I've been sitting on for a while with this. The
"within a release" thing keeps coming up here. But did you sufficiently
consider the fact that Rawhide is "a release", and needs to change like
this? If your position is "we can't change the default stream of a
module mid-release", that implies "...but we can change it between
releases". But how is a 'between releases' change ever going to happen
if it doesn't happen in Rawhide first...which is technically "mid-
release"?
AFAICS even if as a matter of policy something shouldn't be done within
a stable release, anything that can be done between releases needs to
be *technically* possible 'within a release' (i.e. within Rawhide), or
else we can't possibly do development properly, no?
Very good point!
Yes, we definitely need a mechanism to potentially change streams between releases. This is to make it the same as when major software versions change during a distribution upgrade. Even though Modularity respects your choices of a specific stream, it also need to respect your choices not to make a choice (if that makes sense). Basically, when you install a package the way you'd always do by "dnf install package" and it happens to be in a default module stream, that stream gets automatically enabled and the package installed. But what happens when there is a new major Fedora release with a different default stream of that package? Without Modularity, your package would get upgraded to the new version automatically when performing the system upgrade. We need to keep the same behaviour with Modularity as well. So the stream needs to be switched automatically during the upgrade. A very different story of course would be you choosing a specific module stream by "dnf module enable module:stream" and then installing the package from it. In that case, the stream should not be switched because you've made an explicit choice.
And to be clear, we don't have an existing mechanism for that — but we have discussed it extensively [0] and I have documented a specific proposal [1] based on those discussions for that behaviour, discussed that with the DNF team, and opened a bug [2] based on what we agreed on. However, there was no progress on it.
To your second point about rawhide, yes, you're absolutely right. The way we think will be the best to deal with rawhide was to treat it as a special case, and use a similar mechanism to the one mentioned above to — unless you chose a specific stream explicitly — keep you on the default stream with every dnf update, even if it means switching streams. And there are probably other aspects to take into account before making this a reality. But again, not much progress there...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
