On Fri, Jun 21, 2019 at 5:47 PM Adam Williamson <adamw...@fedoraproject.org>
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...

[0] https://pagure.io/modularity/issue/108
[1]
https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/upgrades-and-modules.md
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1664427




> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>


-- 

Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to