Description of problem: Trying to instrall man-pages-de errors out due to file conflicts. Version-Release number of selected component (if applicable): man-pages-de-0.5-3.fc12.noarch man-db-2.5.7-2.fc14.x86_64 How reproducible: Always... Steps to Reproduce: 1. yum -y install man-pages-de 2. 3. Actual results: Downloading Packages: Loaded plugins: auto-update-debuginfo, fastestmirror, fs-snapshot, local, post- : transaction-actions, presto, priorities, protectbase, refresh- : packagekit, refresh-updatesd, remove-with-leaves, rpm-warm- : cache, upgrade-helper, versionlock man-pages-de-0.5-3.fc12.noarch.rpm | 938 kB 00:02 Running rpm_check_debug Running Transaction Test Transaction Check Error: file /usr/share/man/de/man1/manpath.1.gz from install of man-pages-de-0.5-3.fc12.noarch conflicts with file from package man-db-2.5.7-2.fc14.x86_64 file /usr/share/man/de/man1/zsoelim.1.gz from install of man-pages-de-0.5-3.fc12.noarch conflicts with file from package man-db-2.5.7-2.fc14.x86_64 file /usr/share/man/de/man5/manpath.5.gz from install of man-pages-de-0.5-3.fc12.noarch conflicts with file from package man-db-2.5.7-2.fc14.x86_64 file /usr/share/man/de/man8/catman.8.gz from install of man-pages-de-0.5-3.fc12.noarch conflicts with file from package man-db-2.5.7-2.fc14.x86_64 file /usr/share/man/de/man8/mandb.8.gz from install of man-pages-de-0.5-3.fc12.noarch conflicts with file from package man-db-2.5.7-2.fc14.x86_64 Error Summary ------------- Expected results: German man pages installed. Additional info:
It maskes no sense to have the language-specific files in man-db, does it? If I just install English, I don't want to haul extra baggage (French, Chinese, ... man pages) around. OTOH, this would mean either splitting man-db (and such) languagewise or including their manpages in the language-specific sets. A mess either way.
I upgraded to rawhide yesterday and have this issue too. I am wondering why not more people are hit by it. To use yum update i have to use the -x option now ...
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is reported as a blocker in bug #620624.
Actually, I believe that *if* the translated man pages are part of the upstream man-db package, then they should stay in man-db.
*** Bug 620624 has been marked as a duplicate of this bug. ***
Marking this as an F14Target, but maybe it should be escalated to F14Blocker?
Putting this back on the F14alpha blocker since I don't fully understand the alpha criteria on conflicts, since I was the one who removed bug 620624. Feel free to drop it again if this is not a F14 Alpha blocker. Guess it would be quicker just to fix the package? :)
From https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria "No file conflicts or unresolved package dependencies during a media-based (CD/DVD) install" Since this problem is present on the F-14-Alpha media, it is a valid release criteria blocker.
What are the next steps and plans for fixing this bug? Can someone please provide more information? If this is in fact a blocker we can't compose the Fedora 14 Alpha Release Candidate today unless it is fixed.
(In reply to comment #1) > It maskes no sense to have the language-specific files in man-db, does it? If I > just install English, I don't want to haul extra baggage (French, Chinese, ... > man pages) around. OTOH, this would mean either splitting man-db (and such) > languagewise or including their manpages in the language-specific sets. A mess > either way. It's often the case, that a programm ships man pages for several languages. But I don't think, that's negative. Sure it's an "extra baggage", but it keeps the "mess" low, any you always get the latest man pages from upstream. I've read somewhere, that the man-pages-* are outdated (not to say unusable) in comparison with the original English man pages, so I suggest to remove man-pages-de from the distribution... Can someone verify, that the man pages are outdated?.
This bug has existed since April. Where is Robert Albrecht, and does anyone know why he hasn't responded to this bug?
Re: comment #11, removing the package is, I suppose, an option, but that seems like a poor way to solve this bug specifically.
https://admin.fedoraproject.org/pkgdb/acls/name/man-pages-de tells me that provenpackagers can commit to this package, and there are *no* comaintainers listed. Is anyone on the cc list a provenpackager who could help in this case?
(In reply to comment #14) > https://admin.fedoraproject.org/pkgdb/acls/name/man-pages-de tells me that > provenpackagers can commit to this package, and there are *no* comaintainers > listed. Is anyone on the cc list a provenpackager who could help in this case? Yes, I'll delete the man pages that conflict... (Hopefully the list from comment #0 is complete.) This doesn't solve the "outdated issue", but let the alpha ship at least...
(In reply to comment #12) > This bug has existed since April. Where is Robert Albrecht, and does anyone > know why he hasn't responded to this bug? His last build is from 2009-07-24 [1], maybe someone wants to take his packages... [1] http://koji.fedoraproject.org/koji/userinfo?userID=730 ________________________________________________________________________________ I'm running F-13 and can't test this with installing, but I verified by hand, that man-pages-de doesn't conflict with man-db anymore.
man-pages-de-0.5-4.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/man-pages-de-0.5-4.fc14
Moving to ON_QA based on update available on comment#17
Moving to VERIFIED based on F-14-Alpha RC#2 test results. Also, see bodhi feedback.
man-pages-de-0.5-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.