+++ This bug was initially created as a clone of Bug #127005 +++ * checking 3175 files for package collisions existing file /usr/share/man/man3/error.3.gz is not owned by this package 1000 files checked ... 2000 files checked ... 3000 files checked ... * spent 5.34093999863 seconds checking for file collisions * This package is blocked because it wants to overwrite * files belonging to other packages (see messages above). * If you have no clue what this is all about report it * as a bug for this package on http://bugs.gentoo.org package sys-apps/man-pages-2.33 NOT merged No package files given... Grabbing a set. # equery b /usr/share/man/man3/error.3.gz [ Searching for file(s) /usr/share/man/man3/error.3.gz in *... ] mail-mta/qmail-1.03-r16 (/usr/share/man/man3/error.3.gz)
bump. I didn't dare to propose a fix as the qmail ebuild is a bit scary, but as there's a similar hack already in there I think it's as simple as --- /usr/portage/mail-mta/qmail/qmail-1.03-r16.ebuild 2006-07-01 21:39:01.000000000 +0200 +++ qmail-1.03-r16.ebuild 2006-07-20 07:46:18.000000000 +0200 @@ -365,6 +365,8 @@ # Don't install this one, it's provided by ucspi-tcp, bug #127005 rm tcp-environ.5 + # This is provided by man-pages. bug #137207 + rm error.3 into /usr einfo "Installing manpages" I am not sure wether the pages describe the same thing though, so probably a rename would be better instead.
(In reply to comment #1) > I am not sure wether the pages describe the same thing though, so probably a > rename would be better instead. > Both refer to error.h in the synopsis, but the qmail one does not match /usr/include/error.h.
Yes, I looked them up and the qmail one looks very basic on comparison. Looks like all the *.3 pages are documentation for the header files. Since they all use names very similar to general linux syscalls, headerfiles or utilities, perhaps they shouldn't be installed by the ebuild at all, or at least under a different name? coe.3 error.3 fd_move.3 now.3 wait.3 alloc.3 datetime.3 error_str.3 fifo_make.3 sgetopt.3 case.3 direntry.3 error_temp.3 getln.3 stralloc.3 cdb.3 env.3 fd_copy.3 getln2.3 subgetopt.3
6 months on... Is this bug waiting on something inparticular?
*** Bug 166228 has been marked as a duplicate of this bug. ***
AFAIK mail-mta/qmail has been deprecated in favour of netqmail. So in case netqmail does not have that problem I suggest to close this bug. Otherwise, just do not install the *.3 man pages - they are only be interesting to qmail developers, not to normal qmail users.
I just migrated from qmail to netqmail and ran into this issue, so the problem is not solved for netqmail.
*** Bug 155729 has been marked as a duplicate of this bug. ***
*** Bug 132167 has been marked as a duplicate of this bug. ***
Bump for this bug. man-pages just got updated to 2.44 and still collide with mail-mta/(net)qmail. Suggest a review of line 186 of the netqmail ebuild: 186 doman *.[1-8] *.3 man pages are definitely not relevant to users and should not be installed into $MANDIR because of collisions with man-pages. some of the *.1 man pages also look suspicious (e.g., except.1) but do not collide with anything ATM.
(In reply to comment #10) > *.3 man pages are definitely not relevant to users and should not be installed > into $MANDIR because of collisions with man-pages. Where should they be installed instead? > some of the *.1 man pages also look suspicious (e.g., except.1) but do not > collide with anything ATM. These are valid programs which are used in dot-qmail files (~/.qmail*, etc.).
(In reply to comment #11) > (In reply to comment #10) > > *.3 man pages are definitely not relevant to users and should not be installed > > into $MANDIR because of collisions with man-pages. > > Where should they be installed instead? AFAICS either: 1) Not at all, not relevant to users. 2) Somewhere in /usr/share/doc/netqmail-XX for those who really need them (but qmail *developers* can be expected to be working with the source tree anyway) 3) Rename them to e.g. qmail-error.3 and install to $MANDIR/man3 as usual. I like 3 but its your choice. --- netqmail-1.05-r7.ebuild_ 2007-04-12 10:35:02.000000000 +0200 +++ netqmail-1.05-r7.ebuild 2007-04-12 10:35:05.000000000 +0200 @@ -182,6 +182,10 @@ qreceipt qsmhook sendmail tcp-env einfo "Installing manpages" + for f in *.3 + do + mv $f qmail-${f} + done into /usr doman *.[1-8]
bump. Issue remains for newly-released -r8. It keeps two arguably important packages from being installed for a really trivial reason - repeating comment #4 what is this bug waiting for in particular?
(In reply to comment #13) > bump. Issue remains for newly-released -r8. Had you checked ChangeLog, you'd known it hasn't been fixed. > what is this bug waiting for in particular? A solution. Renaming or even leaving out manpages isn't one because it would alter the upstream packaged (net)qmail too much. How about introducing our own man section? X also has its own.
(In reply to comment #14) > A solution. Renaming or even leaving out manpages isn't one because it would > alter the upstream packaged (net)qmail too much. I don't buy this argument, still... > How about introducing our own man section? X also has its own. sounds like a good idea, so let's try that: --- netqmail-1.05-r8.ebuild_ 2007-04-30 15:51:07.000000000 +0200 +++ netqmail-1.05-r8.ebuild 2007-05-03 20:49:33.000000000 +0200 @@ -179,8 +179,17 @@ qreceipt qsmhook sendmail tcp-env einfo "Installing manpages" + MY_MAN_EXTRADIR="/usr/share/man/man3q" + diropts -o root -g root -m 755 + dodir $MY_MAN_EXTRADIR + insinto $MY_MAN_EXTRADIR + insopts -o root -g root -m 755 + for f in *.3; do + mv $f ${f:-1:1}q + done + doins *.3q into /usr - doman *.[1-8] + doman *.[1-2,4-8] dodoc BLURB* CHANGES FAQ INSTALL* PIC* README* REMOVE* SECURITY \ SENDMAIL SYSDEPS TARGETS TEST* THANKS* THOUGHTS TODO* \ (requires some ugly messing around with insopts and friends because there doesn't appear to be something like manopts or mandir, but it does the trick.) Unfortunately this approach requires the addition of the "man3q" section to /etc/man.conf like so: -MANSECT 1:1p:8:2:3:3p:4:5:6:7:9:0p:tcl:n:l:p:o:1x:2x:3x:4x:5x:6x:7x:8x +MANSECT 1:1p:8:2:3:3p:4:5:6:7:9:0p:tcl:n:l:p:o:3q:1x:2x:3x:4x:5x:6x:7x:8x ^^^ as well as probably the adaptation of the several shell auto-completion configs, e.g. /etc/profile.d/tcsh-complete and friends. Seems overkill to me personally but if it does get this thing over with...
Just realized we might get away with the much simpler --- netqmail-1.05-r8.ebuild_ 2007-04-30 15:51:07.000000000 +0200 +++ netqmail-1.05-r8.ebuild 2007-05-03 21:14:17.000000000 +0200 @@ -179,8 +179,11 @@ qreceipt qsmhook sendmail tcp-env einfo "Installing manpages" + for f in *.3; do + mv $f ${f:-1:1}q + done into /usr - doman *.[1-8] + doman *.[1-2,3q,4-8] dodoc BLURB* CHANGES FAQ INSTALL* PIC* README* REMOVE* SECURITY \ SENDMAIL SYSDEPS TARGETS TEST* THANKS* THOUGHTS TODO* \ Pages still end up in ${MANDIR}/man3 instead of man3q but man itself doesn't seem to bother much, even with unaltered man.conf. Only side-effect is that "man error" (etc.) will find qmails error page before the one from man-pages - not sure how to fix that. This is undesireable because most of those pages LOOK like they are documenting linux/libc header files (most make no mention of qmail anywhere) but contain information which is outright WRONG for linux/libc headers. In addition, the qmail headers they do document are not even installed by the ebuild -- so installing their man pages to $MANPATH makes even less sense. I repeat my suggestion to not install those pages, or install them somewhere where they do not mask useful information, e.g. $DOCDIR.
I had to mark 1.05-r8 stable today because of a serious problem with OpenSSL 0.9.8e. However, I'll address the man pages issue in -r9.
*** Bug 211890 has been marked as a duplicate of this bug. ***
qmail team: What do you want to do with this bug? If there is no comment in the next few days, I'll just have netqmail not install the man pages that collide with sys-apps/man-pages.
fixed in 1.06
*** Bug 222885 has been marked as a duplicate of this bug. ***
*** Bug 234365 has been marked as a duplicate of this bug. ***
*** Bug 253608 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > fixed in 1.06 > Well, I would suggest 1.06 to be marked as stable so that people dont constantly run into this problem. I guess that will probably not take long anyway, but just letting you know I ran again into this problem.
I'm sorry if I didn't understand from the other posts, but I have just run into this on one of my servers, and I see that this is several years old, and set as resolved, but what is the fix for this? I see that mail-mta/netqmail-1.06 is still hard masked, and even 5 of the dependencies it says it needs are masked: =sys-apps/ucspi-ssl-0.70-r1 ~amd64 =net-mail/dot-forward-0.71-r3 ~amd64 =sys-process/daemontools-0.76-r6 ~amd64 =virtual/checkpassword-0 ~amd64 =sys-apps/ucspi-tcp-0.88-r17 ~amd64 That's an awful lot of warning signs _not_ to do this upgrade...
(In reply to comment #25) > I'm sorry if I didn't understand from the other posts, but I have just run into > this on one of my servers, and I see that this is several years old, and set as > resolved, but what is the fix for this? I see that mail-mta/netqmail-1.06 is > still hard masked, and even 5 of the dependencies it says it needs are masked: netqmail-1.06 will be unmasked as soon as ucspi-ssl is keyworded for the required archs, but i have no ETA for a stable request yet. anyway, i'm using these ebuilds for a long time now, and they have done a great job.
*** Bug 258520 has been marked as a duplicate of this bug. ***
*** Bug 263463 has been marked as a duplicate of this bug. ***
*** Bug 264302 has been marked as a duplicate of this bug. ***
*** Bug 266629 has been marked as a duplicate of this bug. ***
This problem still exist using current (unkeyworded) packages. Still not fixed for me as using keyworded packages is not an option on this box.
*** Bug 290196 has been marked as a duplicate of this bug. ***
*** Bug 291372 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > *** Bug 291372 has been marked as a duplicate of this bug. *** > This bug still not resolved for me, and I do not understand why the status is RESOLVED FIXED. Start with latest stage3-amd64 and emerge qmail, it will fail! Please add a revision 9 with fix or mark 1.06 as stable.
What's stopping netqmail-1.0.6 from being stabilized? The arches missing in bug 253453 (m68k,mips) will probably never keyword ucspi-ssl. Please don't close this bug as long as it isn't fixed for stable users.
Blocks bug 285213 as well. Please add arches if you think that 1.06 should go stable. Thanks
(In reply to comment #35) > What's stopping netqmail-1.0.6 from being stabilized? > > The arches missing in bug 253453 (m68k,mips) will probably never keyword > ucspi-ssl. After 2 months later, still am hitting this issue on stable amd64 with mail-mta/netqmail-1.05-r8 having file collision with: sys-apps/man-pages-3.23 (/usr/share/man/man3/error.3.bz2)
This is already fixed in 1.06, which IS stable.