Bug 993903 - kdelibs3 possibly affected by F-20 unversioned docdir change
kdelibs3 possibly affected by F-20 unversioned docdir change
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kdelibs3 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
http://fedoraproject.org/wiki/Changes...
: Reopened
Depends On:
Blocks: F20UnversionedDocDirs
  Show dependency treegraph
 
Reported: 2013-08-06 09:04 EDT by Ville Skyttä
Modified: 2013-08-07 03:09 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-06 19:44:56 EDT
Type: ---
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 Ville Skyttä 2013-08-06 09:04:27 EDT
kdelibs3 was identified as a package possibly needing maintainer attention
due to the F-20 unversioned doc dir change. The identification is not
foolproof, it is basically this grep:

    grep -E "(/doc|_docdir|_defaultdocdir).+version" *.spec

Please review your package and make the appropriate changes, if any. A
good starting point is checking the lines output by the above grep for
your specfile. For the vast majority of packages, after the changes,
the expected outcome is that documentation dirs in /usr/share/doc
should no longer contain the package version.

More information and tips:
  https://fedoraproject.org/wiki/Changes/UnversionedDocdirs
  http://thread.gmane.org/gmane.linux.redhat.fedora.devel/183942/focus=183943
  http://thread.gmane.org/gmane.linux.redhat.fedora.devel/183942/focus=183973
Comment 1 Kevin Kofler 2013-08-06 11:00:23 EDT
The qt3 and kdelibs3 docdir are manually and explicitly versioned and this will not change.
Comment 2 Ville Skyttä 2013-08-06 11:12:03 EDT
(In reply to Kevin Kofler from comment #1)
> The qt3 and kdelibs3 docdir are manually and explicitly versioned and this
> will not change.

The reason being what? It deviates from:

1) Other subpackages within the same srpm, some install docs into versioned, some into unversioned dirs now.

2) Practically the rest of the distribution.
Comment 3 Kevin Kofler 2013-08-06 19:44:56 EDT
In kdelibs3's case:
* this affects only the apidocs, whose build is now disabled, and,
* the included "version" is only the major version "3" (as a "major_version" macro, which is how the "version" in the regex is matched), which is required or it would conflict with kdelibs 4.

qt3 is a different story (it uses %{_docdir}/qt-devel-%{version}, I guess it could be changed to ), we can discuss that in the qt3 report if you want, but I'm reluctant to change the docdir there because other packages may depend on it. (In fact, if you enable kdelibs3 apidocs, it needs to reference the qt3 apidocs, and so kdelibs3.spec has the same directory hardcoded.) In fact, I think the whole "unversioned docdir" "feature" is yet another totally pointless incompatible change that can break many packages for exactly zero benefit.
Comment 4 Kevin Kofler 2013-08-06 19:46:04 EDT
The truncated sentence in the parentheses should read: I guess it could be changed to %{_docdir}/qt3-devel.
Comment 5 Ville Skyttä 2013-08-07 03:09:47 EDT
(In reply to Kevin Kofler from comment #3)
> * the included "version" is only the major version "3" (as a "major_version"
> macro, which is how the "version" in the regex is matched), which is
> required or it would conflict with kdelibs 4.

That's fine and doesn't appear to need changes, but the regex also matched the qt3_docdir which on the other hand should be changed to plain unversioned qt3-devel.

> qt3 is a different story (it uses %{_docdir}/qt-devel-%{version}, I guess it
> could be changed to ), we can discuss that in the qt3 report if you want,

I don't think that would be productive use of my time -- this is an accepted F-20 feature, I'd be surprised if it wouldn't become a "MUST" in packaging guidelines soonish, all the needed info is already out there, and nobody else I'm aware of is refusing to use it unless there are valid (parallel install) considerations, so I'm guessing if you're not following the rest of the distro now there will be questions / bug reports later.

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