confcache installs COPYING into /usr/share/doc. this is the generic GPL-2 license file which is already included in ${PORTDIR}/licenses and should not be installed. this is one of the checks that the Aging Ebuilds with Unstable Keywords script (http://gentoo.tamperd.net/stable/index.php) runs and flags as a QA issue.
Kinda hijacking this bug, it also installs all the docs twice: # equery f confcache | grep doc /usr/share/doc /usr/share/doc/confcache /usr/share/doc/confcache-0.3.3 /usr/share/doc/confcache-0.3.3/ChangeLog.gz /usr/share/doc/confcache-0.3.3/PKG-INFO.gz /usr/share/doc/confcache-0.3.3/README.gz /usr/share/doc/confcache/COPYING /usr/share/doc/confcache/ChangeLog /usr/share/doc/confcache/README
Another small fix: betelgeuse@pena /usr/portage/dev-java/ant-core $ eix confcache * dev-util/confcache Available versions: 0.3.3 Installed: 0.3.3 Homepage: http://dev.gentoo.org/~ferringb/${PN} Description: global autoconf cache manager
@Ryan: if there is docs backing up this, point me at them- do a scan of your /usr/share in the meantime, you'll see it's done by several apps (seems to be a matter of ebuild maintainer choice). @others: Commiting it in a few minutes.
(In reply to comment #3) > @Ryan: > if there is docs backing up this, point me at them- do a scan of your > /usr/share in the meantime, you'll see it's done by several apps (seems to be a > matter of ebuild maintainer choice). > > @others: > Commiting it in a few minutes. > http://dev.gentoo.org/~ciaranm/docs/mw-faq/docfiles.txt Don't know where/if this is somewhere in more official documentation. Yes, I know many ebuilds install those files but we should try to clean them.
Ciaran's personal docs he's pushing don't exactly fly as actual policy... Bluntly, the LICENSE/COPYING suggestion there is stupid- it's reliant on a tree being available, and the ebuild in question still being in the tree stating the license. No tree, no license info (thus the "it's in the tree" doesn't fly). Remember also that our binpkgs can be used _without_ portage; again, the tree isn't required for the resultant binaries/pkg that's generated. So... that's a No...
like you said, it's up to the maintainer. i asked on the dev-ml if this was actually something worth filing bugs about and the response was in the affirmative. you're right, there are other packages that install this stuff in /usr/share/doc, and bugs have been/will be filed for them. you're the first to object, although i haven't done a lot of them yet. ;) i'm just trying to tackle some of the mundane QA janitorial work no one ever gets around to. if the info i got was incorrect and there's actually a legal reason to install these files let me know and i'll move on to other work. better bring it up to the maintainer of the script as well. if this is just a personal view i'll be sure to not bother you with it again on other packages you maintain. :) cheers.
Filing further bugs is missing my point here- the suggestion you're poking me on I'm pointing out issues with (iow, not nagging me about it isn't the issue). It's not a legal issue, it's a question of what devs deem should be installed- eg, should a copy of the license be installed or not? Having the license around (imo) is kind of an expected thing, *especially* if the package goes to the trouble of installing it. Only responder to your question was betelgeuse- frankly, that's not really consensus. I'm asking that you raise the issue on dev, get it hammered out rather then further filing bugs on it. While I'm being noisy, keep in mind the efforts *are* appreciated- I'm just suggesting that prior to bugzie'ing people to fix packages, ensure that the changes are actually what everybody agrees to- both ciaran's docs and aziz's ancient script fly in the face of what actually is occuring in the tree. That right there makes me think the majority don't give agree with that suggestion, thus the request for actual discussion on the issue. :)
