Dne 31. 03. 20 v 10:14 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Mar 31, 2020 at 09:25:45AM +0200, Vít Ondruch wrote:
Wouldn't be easier to use something we already have? E.g.
https://src.fedoraproject.org/rpms/fedora-obsolete-packages
Obsoletes in individual rpms have no effect on modules, and any
enabled module "shadows" non-modular rpms that the module declared,
i.e. makes dnf consider only rpms from the module, completely ignoring
rpms from the normal repo, no matter what EVRA they have.
If that sounds wrong to you, you are not alone. But things are as
they are, and this Change is about making upgrades work within the
design of Modularity, hopefully avoiding stuff like [1,2,3,4,5].
I don't think it's going to fix most of them, but it's a move towards a
saner system where modules support packaging best practices (adding
Obsoletes this time).
[1] https://fedoraproject.org/wiki/Common_F31_bugs#Eclipse_module_has_been_reset_to_avoid_shadowing_non-modular_rpms
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1780827
This change won't help with [1] and [2].
I'm quite happy with the workaround we used, because this was a one-time
fix for a quite uncommon situation.
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1747408
IIRC the libgit2 problem was caused by change in stream dependencies.
This will require an additional change in how Context is used.
The overall idea is to introduce upgrade paths among Contexts by simply
stopping changing them. If N:S:C represented a virtual repository
(potentialy also a branch and a build target), we'd finally have upgrade
paths in modularity. DNF has to guess now and no wonder it errors out
from time to time. But this change will require more time, as it changes
stream expansion and the whole build process. I don't think we'll be
able to make it in the Fedora 33 time frame.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1807832
This is a modularity feature.
Modules can provide older packages than distro provides.
That's why it applies the RPM filtering - to hide newer RPMs provided by
distro.
This must be solved by having a good packaging policy and tests.
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1806303
The problem was in misunderstanding how defaults should be removed.
Modularity works across repos and 'updates' don't automatically override
'fedora' -> empty defaults with higher priority must be published in
'updates'
Zbyszek
_______________________________________________
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
_______________________________________________
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
