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 1149306 - man-pages-de file conflicts with procps-ng 3.3.10
Summary: man-pages-de file conflicts with procps-ng 3.3.10
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: man-pages-de
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mario Blättermann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-03 17:43 UTC by Jaromír Cápík
Modified: 2016-02-01 02:00 UTC (History)
4 users (show)

Fixed In Version: man-pages-de-1.7-3.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-10 15:56:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1146203 0 unspecified CLOSED File conflicts with procps-ng 2021-02-22 00:41:40 UTC

Internal Links: 1146203

Description Jaromír Cápík 2014-10-03 17:43:33 UTC
Description of problem:
Hello. With introduction of translated man pages in procps-ng 3.3.10, file conflicts with man-pages-* packages appeared. The conflicting manuals contained in the man-pages-* packages might be many years obsolete and incompatible with procps-ng. Please, remove them from the Rawhide and F21 packages so that the recent manuals can be included in the procps-ng packages.

The list of potentially conflicting man pages to be removed from man-pages-* (if found):
free.1.gz
pgrep.1.gz
pidof.1.gz
pkill.1.gz
pmap.1.gz
ps.1.gz
pwdx.1.gz
skill.1.gz
slabtop.1.gz
snice.1.gz
sysctl.conf.5.gz
sysctl.8.gz
tload.1.gz
top.1.gz
uptime.1.gz
vmstat.8.gz
watch.1.gz
w.1.gz

Thanks in advance.

Regards,
Jaromir.

Comment 1 Fedora Update System 2014-10-03 18:03:21 UTC
man-pages-de-1.7-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/man-pages-de-1.7-2.fc21

Comment 2 Fedora Update System 2014-10-04 16:11:21 UTC
man-pages-de-1.7-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/man-pages-de-1.7-3.fc21

Comment 3 Parag Nemade 2014-10-05 03:11:17 UTC
I will prefer to discuss on bugzilla rather on bodhi update comments.

Mario,
   Here is what happening using dnf with man-pages-de-1.7-2.fc21 update. 
Error: Transaction check error:
  file /usr/share/man/de/man1/uptime.1.gz from install of man-pages-de-1.7-2.fc21.noarch conflicts with file from package procps-ng-3.3.10-2.fc21.x86_64

One can easily test this before or after official build of this fix and when decided procps-ng should keep the man pages then ensuring prior installed procps-ng-3.3.10-2.fc21 package. So, It looked like man-pages-de-1.7-2.fc21 will not be fixing file conflicts.

I also analyzed how man-pages-fr package works,how its fix worked. The reason to remove lots of man pages is to ensure in future man-pages-de tarball if contained one conflicts file then other can be included and to avoid this I added this. However, I closed bug man-pages-pl by providing reasoning that it at all not contain any conflicted man pages so they will never be added in its future releases.

I am sorry for the changelog change but when I looked at it, I see I have not removed your changelog entry but the date got changed which can be fixed in f21 branch easily. Either you can do it or if you want I can fix it.

-* Fri Oct 03 2014 Mario Blättermann <mario.blaettermann> - 1.7-2
+* Wed Sep 24 2014 Mario Blättermann <mario.blaettermann> - 1.7-2

Note man-pages-fr is removing conflicting man pages in %install section whereas I added here in %prep section which is more convenient.

Comment 4 Fedora Update System 2014-10-05 08:13:32 UTC
Package man-pages-de-1.7-3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing man-pages-de-1.7-3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12198/man-pages-de-1.7-3.fc21
then log in and leave karma (feedback).

Comment 5 Mario Blättermann 2014-10-05 08:36:46 UTC
(In reply to Parag from comment #3)
> I also analyzed how man-pages-fr package works,how its fix worked. The
> reason to remove lots of man pages is to ensure in future man-pages-de
> tarball if contained one conflicts file then other can be included and to
> avoid this I added this. However, I closed bug man-pages-pl by providing
> reasoning that it at all not contain any conflicted man pages so they will
> never be added in its future releases.

I'm involved in upstream development of man-pages-de. Mainly we concentrate our effort to the Linux programming manuals and related stuff from the man-pages package. The man pages from procps-ng came from external contributors, and we won't accept other procps-based translations in the future. Only free.1.po and uptime.1.po need to be removed, no more than that.

> 
> I am sorry for the changelog change but when I looked at it, I see I have
> not removed your changelog entry but the date got changed which can be fixed
> in f21 branch easily. Either you can do it or if you want I can fix it.
> 
> -* Fri Oct 03 2014 Mario Blättermann <mario.blaettermann> - 1.7-2
> +* Wed Sep 24 2014 Mario Blättermann <mario.blaettermann> - 1.7-2
> 
I'll fix it in the next update, which will come in a few weeks, some time before Debian Jessie gets frozen (where man-pages-de is based on).

Again, nice to have provenpackagers in many cases, but please wait for the answer from package maintainers or co-maintainers more than a few hours before you change something. I'm not online 24 hours a day to response immediately.

Comment 6 Parag Nemade 2014-10-05 11:15:00 UTC
Okay. I will wait before making any further changes to your packages. Actually I got used to with what Gnome maintainers used to do, they do not wait for the fix from actual package maintainer that they want to see in Gnome packages.

I see you are upstream developer so I have some suggestions about upstream source
1) this package can be built successfully with just BuildRequires: po4a
So if I look only from packaging perspective then upstream may want to add rules in configure script to make sure it will fail for other packages if they are not in spec BuildRequires. 

2) you may want to remove all entries in upstream for procps.links file reference in Makefile*

Other thing as the file conficts is fixed now, I will not work further on this package but I did build this package in mock with several combinations of BuildRequires and already concluded that if this package only contains

BuildRequires: po4a
BuildRequires: isdn4k-utils

you will see uptime man page packaged if you are not going to remove it manually in %prep

So when I tried to find the connection between "BuildRequires: isdn4k-utils" and uptime.1.gz man page, I saw that when you add BR: isdn4k-utils, root.log showed it installed procps-ng also and thus uptime.1.gz
This is the reason why -2 build failed to fix this bug.

Comment 7 Mario Blättermann 2014-10-05 12:55:16 UTC
(In reply to Parag from comment #6)
> 1) this package can be built successfully with just BuildRequires: po4a
> So if I look only from packaging perspective then upstream may want to add
> rules in configure script to make sure it will fail for other packages if
> they are not in spec BuildRequires. 
> 
It is not intended to enforcing build the not man-pages based files (coreutils, findutils etc.). Keep in mind, not all of the extra dependencies are available from all distributions, Mageia doesn't have recutils, for example, and Fedora doesn't have binkd, lilo and sysvinit-tools. The upstream po files will be updated from Debian packages, so a packager from another distribution could decide to drop some package requirements due to differing versions (for example, util-linux is in Debian v2.20 from 2011, while we already ship the current v2.25). In that case sometimes very "sparse" files will be built, and even file can fall below the threshold of 80% for po4a and the file doesn't get build. But anyway, we will further discuss this upstream.

> 2) you may want to remove all entries in upstream for procps.links file
> reference in Makefile*
> 
This can be done on packager's side only. As already mentioned, man-pages-de is in fact a Debian project, and procps-3.3.10 hasn't reached the Debian repos, nor in Sid neither even in Experimental. So the procps-ng man pages will remain in the upstream Git for the next years, until the successor of the upcoming Jessie gets frozen.

> Other thing as the file conficts is fixed now, I will not work further on
> this package but I did build this package in mock with several combinations
> of BuildRequires and already concluded that if this package only contains
> 
> BuildRequires: po4a
> BuildRequires: isdn4k-utils
> 
> you will see uptime man page packaged if you are not going to remove it
> manually in %prep
> 
> So when I tried to find the connection between "BuildRequires: isdn4k-utils"
> and uptime.1.gz man page, I saw that when you add BR: isdn4k-utils, root.log
> showed it installed procps-ng also and thus uptime.1.gz
> This is the reason why -2 build failed to fix this bug.

I was also a bit confused about the presence of uptime.1 after removing procps-ng from BR. But why the translated free.1 doesn't get built although it comes from the same package...? That's strange.

Comment 8 Parag Nemade 2014-10-05 13:16:59 UTC
Thank you for the explanation. 

I see procps-ng provides man1 free page whereas man-pages-de provides man3 free page.

Comment 9 Fedora Update System 2014-10-10 15:56:39 UTC
man-pages-de-1.7-3.fc21 has been pushed to the Fedora 21 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.