kuku@kuku ~ $ ACCEPT_KEYWORDS="~x86" emerge -pvt digikam These are the packages that I would merge, in reverse order: Calculating dependencies ...done! [ebuild N ] media-gfx/digikam-0.8.1 -arts -debug -xinerama 0 kB kuku@kuku ~ $ ls -alh /usr/portage/distfiles/digikam-* -rw-rw-r-- 1 root portage 3,7M sty 21 16:17 /usr/portage/distfiles/digikam-0.8.1.tar.bz2 -rw-rw-r-- 1 root portage 42M lis 25 23:25 /usr/portage/distfiles/digikam-doc-0.8.0.tar.bz2 as you see the docs for digicam are over 42 MB and the sources itself are only 4MB so I think it should be possible to disable the downloading od the doc files
The doc use flag is for developer documentation, user documentation does always get installed, unless you't have "nodocs" in FEATURES, which doesn't affect downloading, though.
*** Bug 130749 has been marked as a duplicate of this bug. ***
May I ask why are we forcing people on dialup etc. to download 40+ megs (10x more than the whole app) of stuff they don't want/need?
See comment #1.
So, should I open another bug with title: "Please add "nouserdoc" USE flag to gentoo" or something like that? :) I really-really don't want to download such a huge docs, and as it turned out, I'm not alone :). What do you think? And please sorry for dup. Honestly, I did a search on 'digikam doc' - it gave me 6 bugs, excluding this for some reason.
(In reply to comment #5) > So, should I open another bug with title: > "Please add "nouserdoc" USE flag to gentoo" or something like that? :) > I really-really don't want to download such a huge docs, and as it turned out, > I'm not alone :). > What do you think? no* use flags shouldn't even exist, personally I wouldn't object having a devdoc and a userdoc use flag, though. To request this, a discussion on the gentoo-dev list would probably be better suited, but iirc this happened once and was shot down, with the argument that there's the nodoc feature flag. And when you look e.g. at Gnome packages for example, not even the doc use flag is always respected. It's a matter of consistency and maintenance cost in the first place. Admitted, using Gentoo and being solely dependend on dialup sucks.
Not that it sucks, but sometimes I just refuse to download huge apps that are not-critical for me :). (and also deltup worked _quite_ well until it became totally broken) In this case I _want_ digikam on my system :). So what can I do? Let me see: 1. Somehow reach developers crowd (IRC, gentoo-dev@gentoo.org, forums) 2. File a wish/bug Right? What's the best/preferrable? Maybe some other way? :) Thanks for your input! With best wishes, Dmitry.
(In reply to comment #4) > See comment #1. Yeah, I did, but it doesn't make much sense: <snip> 03 Dec 2005; Carsten Lohrke <carlo@gentoo.org> +digikam-0.7.4-r1.ebuild, +digikam-0.8.0-r1.ebuild: install user docs always </snip> This change was made fairly recently - I didn't actually notice that anyone would request this; since then people are requesting the exact opposite. 0.7.4 still had USE=doc and noone complained: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-gfx/digikam/digikam-0.7.4.ebuild?hideattic=0&rev=1.4&view=markup Really, common sense >> policy or some vague use flag description. The docs tarball is bigger than kernel sources... uh.
(In reply to comment #8) > This change was made fairly recently No, it was single wrong ebuild. For everything else please refer to my previous comments or discuss it on gentoo-dev.
Well, while waiting for this bug to become resolved I copied digikam's ebuild to my portage overlay and removed all the doc stuff out of it. Kind of a solution to me :))).
Eh, so.... http://tinyurl.com/pv8g6 Please, put the USE="doc" back to the ebuild, there's apparently no such policy similar to what you've stated in Comment #1... If you wish to discuss what's in use.desc, then revive that thread, meanwhile we could stop annoying people w/ this cruft.
Sorry that I didn't take part in that "discussion", but it's meaningless with so few voices and it also missed a few point (as e.g. there is no difference made between stuff installed vs. downloaded). I would of course follow a clear policy, if we had one (and I'd welcome that, as it is indeed handled very different between maintiners/teams), but for now I simply say no.
Removing myself, useless downloads for t3h win.
I think common sense should be relevant here, more than policies and documentation. QA team seems to not have problems to a semi-abuse of doc useflag under the rule of "requires extra download/time". An alternative would be to ask upstream to split the packages by language and use LINGUAS setting to decide which one download. I'll try to get a hold of someone in digikam's team later on. Anyway if nobody in QA disagrees tomorrow I would add the doc useflag. Users are more important than policies.
The doc USE flag should be used when downloading/installing the documentation requires extra dependencies, a lot of extra space, or takes awhile to install (imho). That seems to be the guideline that people follow, so adding a doc USE flag here makes perfect sense to me. If you can get upstream to make it a more sane download (split up the languages), then you can get rid of the flag, but until then, please add the flag. (Anyone else on qa, you are welcome to disagree with me an offer a better solution, but I don't see one :) )
On a side note, this is how we (ab?)use the doc flag in dev-embedded/avr-libc :)
(In reply to comment #14) > I think common sense should be relevant here, more than policies and > documentation. My idea of common sense is it to treat all KDE packages by the same standard. If you changes this arbitrarily, you can take care for this stuff in future.
I would treat all by the same standard if all the packages had 10MB of extra documentation every 1MB of source code, that would be about 60 MB for amaroK.. Not all packages are the same identical thing, so while using the same standard main features, you need to tweak them on a per package basis. In this case, this is overkill to download every time.
The new setup is in place, I'll take care of digiKam from now on, if nobody else wants to. In any case I'll write a maintainer's guide so that if I'll ever go MIA you won't be in trouble.
