Bug 1279639

Summary: Conflicting manual pages
Product: [Fedora] Fedora Reporter: Anton Guda <atu>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: davejohansen, jakub, jwakely, law, mpolacek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-10 12:27:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anton Guda 2015-11-09 22:27:53 UTC 
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 12:56:26 UTC 
Seems this is a result of doxygen >= 1.8.10, which breaks the libstdc++ man pages generation.
Comment 2 Anton Guda 2015-12-08 13:14:58 UTC 
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 14:06:07 UTC 
(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 17:39:14 UTC 
+MAN_EXTENSION          = .3c++
I suppose, this is the best solution.
Comment 5 Jonathan Wakely 2015-12-08 17:48:50 UTC 
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 12:01:44 UTC 
I've reported the doxygen bug:
https://bugzilla.gnome.org/show_bug.cgi?id=759241
Comment 7 Anton Guda 2015-12-10 12:27:24 UTC 
Fixed in 5.3.1-2.fc24. Thanks!