x11-proto/damageproto-1.1.0 installs its documentation in /usr/share/doc/damageproto. It should be /usr/share/doc/damageproto-${PV} instead.
(In reply to comment #0) > It should be /usr/share/doc/damageproto-${PV} instead. Better yet, /usr/share/doc/damageproto-${PF} :)
We should do whatever's normal in autotools rather than hacking around in the ebuild. I haven't looked into it, so I don't know offhand whether versioned or not is typical.
(In reply to comment #2) > We should do whatever's normal in autotools rather than hacking around in the > ebuild. Hm, the Ebuild HOWTO in the dev handbook says the following: # Documentation files are installed in /usr/share/doc, into a subdirectory # reflecting the name, version, and revision of the particular program.
(In reply to comment #3) > Hm, the Ebuild HOWTO in the dev handbook says the following: > # Documentation files are installed in /usr/share/doc, into a subdirectory > # reflecting the name, version, and revision of the particular program. > Right, which usually applies to doc files installed explicitly by the ebuild. In this case, the doc file is installed by autotools. Unfortunately, this means that damageproto currently has two entries under /usr/share. dia and libxcb are also guilty of this. It's unclear to me what the correct solution is. I'm not sure if our doc locations are specific to us or if many distributions use them.
(In reply to comment #4) > Right, which usually applies to doc files installed explicitly by the ebuild. > In this case, the doc file is installed by autotools. Unfortunately, this > means that damageproto currently has two entries under /usr/share. > > dia and libxcb are also guilty of this. It's unclear to me what the correct > solution is. I'm not sure if our doc locations are specific to us or if many > distributions use them. I suppose this happens because it both installs docs normally and via dodoc? We should probably change the doc dir with docinto().
(In reply to comment #5) > I suppose this happens because it both installs docs normally and via dodoc? We > should probably change the doc dir with docinto(). > Yes. You mean we should change our install location to drop the version to match what upstream wants?
(In reply to comment #6) > Yes. You mean we should change our install location to drop the version to > match what upstream wants? Yes. It's cleaner and easier than hacking around the build system when using x-modular.eclass, and the difference is only relevant for slotted packages, of which we have none.
(In reply to comment #7) > Yes. It's cleaner and easier than hacking around the build system when using > x-modular.eclass, and the difference is only relevant for slotted packages, of > which we have none. Alright.
Hmm, what do you think about doing this for all proto packages, since I'm sure many of the future packages will begin to do this?
(In reply to comment #9) > Hmm, what do you think about doing this for all proto packages, since I'm sure > many of the future packages will begin to do this? All the dodoc() calls are in the eclass, AFAIK. Changing it in there should take care of everything, and that's what I meant even if I didn't say it.
Thought about this more. I agree that these should all get stuck in $PF, since that's what the Gentoo docs say. Should be easy enough to pass a --docdir or whatever flag in the eclass.
*** Bug 169934 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Thought about this more. I agree that these should all get stuck in $PF, since > that's what the Gentoo docs say. Should be easy enough to pass a --docdir or > whatever flag in the eclass. > damageproto uses the following to install its docs: damagedocdir = $(datadir)/doc/$(PACKAGE) So I don't think it would be that simple.
(In reply to comment #13) > (In reply to comment #11) > > Thought about this more. I agree that these should all get stuck in $PF, since > > that's what the Gentoo docs say. Should be easy enough to pass a --docdir or > > whatever flag in the eclass. > > > > damageproto uses the following to install its docs: > damagedocdir = $(datadir)/doc/$(PACKAGE) I guess we'll have to look for instances of that and try to fix them. >
Adding: ${PN/proto/}docdir=/usr/share/doc/${PF} to make install works for me
Created attachment 130531 [details, diff] x-modular.eclass patch Suggested patch for x-modular.eclass. The patch works OK for me with randrproto-1.2.1 and compositeproto-0.4 too.
*** Bug 241558 has been marked as a duplicate of this bug. ***
*** Bug 234488 has been marked as a duplicate of this bug. ***
revision 1.106 date: 2009-03-03 17:26:20 +0100; author: remi; state: Exp; lines: +13 -5; commitid: 7a5b49ad5a2b4567; install proto docs in /usr/share/doc/${PF} (fixes bug #164917) Fixed in portage, thanks a bunch for the patch :)
What about libxcb? It was also mentioned in this bug along with dia which has been fixed meanwhile. Adding "--docdir=/usr/share/doc/${PF}" should do here.
(In reply to comment #20) > What about libxcb? It was also mentioned in this bug along with dia which has > been fixed meanwhile. > > Adding "--docdir=/usr/share/doc/${PF}" should do here. > This is now bug #296096.
