Bug 1279639 - Conflicting manual pages
Conflicting manual pages
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-09 17:27 EST by Anton Guda
Modified: 2015-12-10 07:27 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-10 07:27:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anton Guda 2015-11-09 17:27:53 EST
Description of problem:
gcc 5.2.1-[45] have some man pages, conflicting with man-pages package.

/usr/share/man/man3/random.3.gz from install of
libstdc++-docs-5.2.1-4.fc24.x86_64 conflicts with file from package man-pages-4.02-2.fc24.noarch
file /usr/share/man/man3/regex.3.gz from install of 
libstdc++-docs-5.2.1-4.fc24.x86_64 conflicts with file from package man-pages-4.02-2.fc24.noarch

And provides useless /usr/share/man/man3/todo.3.gz

Version-Release number of selected component (if applicable):
libstdc++-docs-5.2.1-5.fc24 


How reproducible:
Always

Steps to Reproduce:
1. Try to update gcc (with libtool)

Actual results:
Conflicting files found - no update.


Expected results:
NO conflicting files.


Additional info:
Man pages under consideration is not a copy of well-known libc man pages.
It may be worth to make a rule for such C++ related pages.
Comment 1 Jakub Jelinek 2015-12-08 07:56:26 EST
Seems this is a result of doxygen >= 1.8.10, which breaks the libstdc++ man pages generation.
Comment 2 Anton Guda 2015-12-08 08:14:58 EST
May be, but we can rename files it by hand.
For example: regex.3.gz to stl_regex.3.gz.
Or by other common rule.
If required, i can make patch for spec.
Comment 3 Jonathan Wakely 2015-12-08 09:06:07 EST
(In reply to Anton Guda from comment #2)
> May be, but we can rename files it by hand.
> For example: regex.3.gz to stl_regex.3.gz.
> Or by other common rule.
> If required, i can make patch for spec.

That would be a terrible idea IMHO. No-one is ever going to say "man stl_regex" because (1) they won't know that's what the man-page is called and  (2) <regex> is not even part of "the STL".

Unless we can coerce Doxygen into its old behaviour it would be better to simply delete those pages. A simple workaround would be to put them in a separate section for now:

--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -1936,7 +1943,7 @@ MAN_OUTPUT             = man
 # The default value is: .3.
 # This tag requires that the tag GENERATE_MAN is set to YES.
 
-MAN_EXTENSION          = .3
+MAN_EXTENSION          = .3c++
 
 # If the MAN_LINKS tag is set to YES and doxygen generates man output, then it
 # will generate one additional man file for each entity documented in the real
Comment 4 Anton Guda 2015-12-08 12:39:14 EST
+MAN_EXTENSION          = .3c++
I suppose, this is the best solution.
Comment 5 Jonathan Wakely 2015-12-08 12:48:50 EST
It turns out there's a doxygen bug which causes it to stop processing at a particular file, and then we don't clean up the generated output to remove the unwanted files like todo.3 and random.3

By skipping that particular file the process can finish, and the unwanted files are gone.  Moving the files to a new section might make sense anyway, but I'll investigate doing that in upstream GCC.
Comment 6 Jonathan Wakely 2015-12-09 07:01:44 EST
I've reported the doxygen bug:
https://bugzilla.gnome.org/show_bug.cgi?id=759241
Comment 7 Anton Guda 2015-12-10 07:27:24 EST
Fixed in 5.3.1-2.fc24. Thanks!

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