Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Mar 5, 2019 at 3:17 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 2019-03-04 at 08:47 +0100, Miroslav Suchý wrote:
> Dne 04. 03. 19 v 7:36 Richard W.M. Jones napsal(a):
> > Why is the --setopt parameter needed?  Couldn't that be based on
> > $releasever?
>
> For the record - we are speaking about:
>
>   --setopt=module_platform_id=platform:f30
>
> I spoke to DNF team and:
>
>   * there is no definition of platform_id
>   * while it seams that it can be constructed from $RELEASEVER, there is no guarantee that it will be this way in future
> (even soft gurantee, i.e. there is no documentation)
>   * it is only defined that module_platform_id is derived from PLATFORM_ID from /etc/os-release
>   * that package we get only after upgrade
>   * but for the upgrade we need new PLATFORM_ID
>   * DNF cannot construct it, because the construction method is not defined
>
> ... and circle is closed. So yes, we need it until there will be documentation how to derive PLATFORM_ID of (next) release.

Well, we have had a bug open on this for some time - at least, as I
understand it, they're the same:

https://bugzilla.redhat.com/show_bug.cgi?id=1656509

which suggests that this is intended to be a fix for it:

https://github.com/rpm-software-management/dnf-plugins-extras/pull/143

though it seems like it may not exactly be complete...

It would be good if DNF team could clarify this, because if they are
expecting that this will stay as-is and people will need to explicitly
specify the module_platform_id on upgrade, we are gonna need to have a
conversation about that and, if it sticks, update the documentation and
also ensure GNOME Software DTRT for graphical upgrades.

I agree, this behavior is not nice. DNF team cannot do much here because
1. Format of the platform ID cannot be generated from releasever. The definition of platform string is too general. It only requires ":" inside therefore we cannot predict if missing module require is platform or not.
2. There were also discussions about providing the platform ID from metadata, but I have no information about the state of the initiative.

I am going to reopen the issue with Modularity team and I hope for the best.

Jaroslav


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux