Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1366793 - Nothing obsoletes retired dnf-langpacks packages, breaks upgrade from Fedora 23 to 25+
Summary: Nothing obsoletes retired dnf-langpacks packages, breaks upgrade from Fedora ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: ---
Assignee: Igor Gnatenko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 1374048 (view as bug list)
Depends On:
Blocks: F25BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2016-08-12 20:40 UTC by Adam Williamson
Modified: 2016-09-11 23:45 UTC (History)
11 users (show)

Fixed In Version: dnf-1.1.10-2.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-11 23:45:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Adam Williamson 2016-08-12 20:40:26 UTC
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).

Comment 1 Parag Nemade 2016-08-13 01:48:16 UTC
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.

Comment 2 Adam Williamson 2016-08-13 03:50:55 UTC
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.

Comment 3 Parag Nemade 2016-08-13 06:09:54 UTC
You are right but then there is no replacement for python3-dnf-langpacks. I am not sure then who can obsolete it.

Comment 4 Adam Williamson 2016-08-14 16:16:06 UTC
that's why I suggested dnf...

Comment 5 Parag Nemade 2016-08-14 17:21:12 UTC
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.

Comment 6 Honza Silhan 2016-08-15 11:54:55 UTC
we should do that in dnf.spec

Comment 7 Igor Gnatenko 2016-08-15 15:07:44 UTC
Though I'm pretty sure base metapackages must do that, but comps doesn't support it.

Comment 8 Geoffrey Marr 2016-08-15 19:04:35 UTC
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

Comment 9 Adam Williamson 2016-08-15 23:47:51 UTC
FPC ticket filed: https://fedorahosted.org/fpc/ticket/645

Comment 10 Zbigniew Jędrzejewski-Szmek 2016-08-18 23:19:15 UTC
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.

Comment 11 Adam Williamson 2016-08-19 00:07:08 UTC
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.

Comment 12 Zbigniew Jędrzejewski-Szmek 2016-08-19 01:46:06 UTC
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.

Comment 13 Parag Nemade 2016-08-19 05:41:40 UTC
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?

Comment 14 Adam Williamson 2016-08-19 05:50:41 UTC
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.

Comment 15 Adam Williamson 2016-08-19 05:51:33 UTC
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.

Comment 16 Adam Williamson 2016-08-22 17:21:39 UTC
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?

Comment 17 Geoffrey Marr 2016-08-22 22:13:13 UTC
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

Comment 18 Parag Nemade 2016-08-23 11:54:32 UTC
(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

Comment 19 Adam Williamson 2016-08-23 14:52:04 UTC
it was just a passing thought, I wasn't saying it was the end of the world or anything.

Comment 20 Geoffrey Marr 2016-08-29 19:42:25 UTC
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

Comment 21 Igor Gnatenko 2016-09-08 08:56:13 UTC
*** Bug 1374048 has been marked as a duplicate of this bug. ***

Comment 22 Fedora Update System 2016-09-08 09:24:37 UTC
dnf-1.1.10-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-92da7f2fe3

Comment 23 Fedora Update System 2016-09-09 06:25:17 UTC
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

Comment 24 Fedora Update System 2016-09-11 23:45:32 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.