Most upgrades from Fedora 23 to Fedora 25 or Rawhide currently fail due to an issue with the retirement of dnf-langpacks. Fedora 23 installs tend to have dnf-langpacks and python3-dnf-langpacks installed. Nothing in Fedora 25+ obsoletes these packages, so when you try to upgrade, dnf will try to keep them installed; but their dependencies are no longer available in F25+, so it fails. You can see this in e.g. this test, of an F23 KDE install to Rawhide: https://openqa.stg.fedoraproject.org/tests/31544 the exact errors are: Error: package python3-dnf-langpacks-0.15.1-1.fc23.noarch requires python(abi) = 3.4, but none of the providers can be installed. package dnf-langpacks-0.15.1-1.fc23.noarch requires python3-dnf-langpacks = 0.15.1-1.fc23, but none of the providers can be installed. Something - I guess langpacks or dnf - should be obsoleting the packages previously built from the dnf-langpacks source package. Proposing as a Beta blocker, "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." - https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria#Upgrade_requirements (though probably --allowerasing would work around this, so we may not consider it a blocker).
I think dnf is not the right place and we don't have binary langpacks main rpm. In this case then we may need to think on generating binary langpacks rpm and obsolete python3-dnf-langpacks packages. I will work on this next week. Thank you Adam for reporting this bug against langpacks.
note that I think for this to work properly, the Obsoletes: has to be in a package that we can guarantee will be installed on all systems which have the to-be-obsoleted packages. That is, if package Y obsoletes package X, but the user's system has package X installed but not package Y (and nothing else will cause Y to be pulled in as a dependency), 'dnf update' or 'dnf system-upgrade' will not pull in package Y to replace package X. It will do so if package Y Provides: X as well as Obsoletes: X, but this isn't always considered the 'right' thing to do if Y doesn't really 'provide' whatever functionality X provided. If it does, though, that's an OK way to do it.
You are right but then there is no replacement for python3-dnf-langpacks. I am not sure then who can obsolete it.
that's why I suggested dnf...
This is the request to DNF developers to consider obsoleting "dnf-langpacks" package in dnf.spec to fix the issue described in this bug description.
we should do that in dnf.spec
Though I'm pretty sure base metapackages must do that, but comps doesn't support it.
Discussed during the 2016-08-15 blocker review meeting: [1] The decision to delay the classification of this bug was made as we are not sure whether 'workarounding' this with allowerasing (or equivalent) is acceptable, and can't really decide in the absence of any packaging policy covering what to do with retired packages if Obsoletes + Provides is not appropriate. The current plan is to consult with FPC to find the proper course of action. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-08-15/f25-blocker-review.2016-08-15-16.00.txt
FPC ticket filed: https://fedorahosted.org/fpc/ticket/645
Forcing users to use --allowerasing is not a good solution: the fact that the upgrade fails is confusing for users, the error message is cryptic, and even if they understand that this is caused by a package that has no upgrade, they don't know, without doing research, if dnf-langpacks is something important and if their system will break without it. Breaking the upgrade path should be avoided if at all possible. I don't think an FPC policy is needed for this case: dnf-langpacks has been replaced, and Provides/Obsoletes should be added as necessary so that upgrade goes through without any hiccups. The only question would be in what packages exactly those Provides/Obsoletes should be added. But FPC does not need to be involved in this.
well, the reason I want FPC to look at it is simply because there is absolutely no policy on this. It isn't really clear, to Parag or I, what the best way forward is here; in such cases it's natural to go and look at the packaging policies and guidelines for guidance. So I did, and found...nothing. That's why I filed an FPC issue.
I totally agree that the guidelines have a big gap for obsolete-but-not-replaced packages. But it doesn't apply to this specific case: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages is pretty clear: > In the event that it becomes necessary to rename or replace an existing package, the new package should make the change transparent to end users to the extent applicable. > If a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes from above.
Hi Jan Silhan, If possible can dnf update be released in F25+ to obsolete dnf-langpacks soon? About FPC involvement, We got dnf as a package that is always available in Fedora installation to obsolete this dnf-langpacks, but what if we will come across a situation where a package need to be retired and there is no relevant package to obsolete it?
zbigniew: no, that doesn't cover this case. The problem is that the new langpacks implementation is kinda different, and there actually *is* no commonly-installed binary package that can reasonably be said to 'replace' the dnf-langpacks binary packages. I think having dnf obsolete (but not provide) them is a reasonable choice, but that's really just, you know, my opinion, man. We don't have anything we can point to and say 'look, this is the guideline which says that's the best thing to do'. Which is the problem.
For details on the new system, see https://fedoraproject.org/wiki/Changes/LangpacksInstallationWithRPMWeakDependencies - should make it clear why there is no single binary package we can say is 'replacing' dnf-langpacks.
of course, now I think about it, as well as the straightforward packaging issue here, there's a genuine functionality issue...was any thought given to the transition from the old langpacks system to the new one on system upgrade? is there anything in place to try and make sure people actually get the correct bits installed on upgrade so they will get correct translations installed in future?
Discussed during the 2016-08-22 blocker review meeting: [1] The decision to delay the classification of this bug as a blocker was made as it's not entirely clear what the criteria surrounding this bug are, and are delaying so that FPC can weigh-in with their input. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-08-22/f25-blocker-review.2016-08-22-16.00.txt
(In reply to Adam Williamson from comment #16) > of course, now I think about it, as well as the straightforward packaging > issue here, there's a genuine functionality issue...was any thought given to > the transition from the old langpacks system to the new one on system > upgrade? is there anything in place to try and make sure people actually get > the correct bits installed on upgrade so they will get correct translations > installed in future? Its the dnf developers who left no choice for dnf-langpacks to get required functionality from dnf. I requested one and only one post-resolve kind of hook that was present in yum but was not provided by dnf. The langpacks plugin was good and working fine just needed dnf to provide that hook that will re-resolve the transaction to pick any langpacks packages but dnf developers totally denied on that part and given weakdeps approach to install langpacks. I could have kept dnf-langpacks plugin along with weakdep approach but it did not make sense to me, hence retired dnf-langpacks. Sorry I did not consider upgrade issue while retiring dnf-langpacks because I know this replacement is not a real replacement but is an alternative to langpacks plugin installation. But I also think existing langpacks packages should get updated fine like any other packages from f23 to f25 as weakdeps approach is just rpm based that used supplements tag. If this is really getting so much problematic for releng/QA then should I unretire dnf-langpacks for now till we find some solution? BTW the fix to dnf.spec is already upstream now, see https://github.com/rpm-software-management/dnf/commit/dbc187027b129c46f0e6cfdf9add7e639d039912
it was just a passing thought, I wasn't saying it was the end of the world or anything.
Discussed during the 2016-08-29 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as, while there is no clear policy on this particular issue, the consensus was that this bug violates the following Beta criteria: "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed." [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-08-29/f25-blocker-review.2016-08-29-16.00.txt
*** Bug 1374048 has been marked as a duplicate of this bug. ***
dnf-1.1.10-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-92da7f2fe3
dnf-1.1.10-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-92da7f2fe3
dnf-1.1.10-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.