There are tons of packages that are completly arch independant, and it is kinda foolish (as well as unconfortable) to add keywords for some arch other than x86 just to make a simple package as ispell-es to unmask it. (I suspect that if one doesn't define the KEYWORD variable inside the script, one gets the same efect. I left it in your hands)
we arent about to start adding KEYWORDS for arch's we've never tested on ... if you want better sparc support, e-mail sparc@gentoo.org ... if you want better ppc support, e-mail ppc@gentoo.org ... if you want better alpha support, e-mail alpha@gentoo.org ...
You seem to be meesing my point here. I'm trying to help gentoo on sparc a bit, by testing and asking for the sparc keyword to be included in the packages I've tested (you can check the bugs I've submitted trough bugzilla for more info). But the thing is, that there are packages that are arquitecture independent. This implicates that they don't have to be tested on each arch. As an example of this, I'll add to this comment a list of the packages that are non-arch-depentend on some other distro (e.g. using slack-current). Please take a *good* look at this list, and try to get my point: a/etc-5.0-noarch-9.tgz a/hotplug-2002_08_26-noarch-1.tgz ap/gnu-gs-fonts-6.0-noarch-1.tgz ap/man-pages-1.53-noarch-1.tgz d/autoconf-2.54-noarch-1.tgz d/automake-1.7-noarch-2.tgz f/linux-howtos-20020507-noarch-1.tgz f/linux-faqs-20020507-noarch-1.tgz f/linux-mini-howtos-20020507-noarch-1.tgz k/kernel-source-2.4.19-noarch-1.tgz kdei/kde-i18n(all of the lenguages)-noarch-1.tgz kdei/koffice-i18n-(all of the lenguages)-noarch-1.tgz l/glibc-i18n-2.3.1-noarch-1.tgz l/aspell-en-0.51_0-noarch-1.tgz t/tetex-doc-20021225-noarch-1.tgz x/xfree86-docs-4.2.1.1-noarch-1.tgz x/xfree86-fonts-100dpi-4.2.1-noarch-1.tgz x/xfree86-fonts-cyrillic-4.2.1-noarch-1.tgz x/xfree86-fonts-misc-4.2.1-noarch-1.tgz x/xfree86-fonts-scale-4.2.1-noarch-1.tgz x/xfree86-docs-html-4.2.1.1-noarch-1.tgz
i still maintain my position that this is not a good idea ... we force people to add arch's to KEYWORDS as a matter of quality control the *only* time this would be useful is for packages that install HTML or PDF only files ... and the number of packages that exist for this isnt great enough to warrant this another good reason for not having an arch-idependent keyword is that as someone ports to a new arch, they can stress test each package as they go ... they'd have to add their arch to the package ... in fact, some of the packages you show dont apply to Gentoo because we dont package up things the way slackware does at any rate, ill pass this along to the rest of the Gentoo dev's and see what people think
just wanna express my 2 cents...I think this would do more harm than good, just adding more KEYWORDS another set of possibilities for error etc, and at some point its possible that these packages could change or need a separate patch. I'm glad to see ideas though would never wanna discourage that and thanks for helping out :)
I think you missed the point. Its not really weather its related to an 'arch', or rather arch dependant, but if it was tested to work on that 'arch'. A better way to think of it, is: "Was it tested on that profile?" If we thus had 'default-blue' and 'default-green' profiles, we would rather have had ACCEPT_KEYWORDS="blue green" or whatever. We basically just use arch to devide things into catagory (profile), because it is the logicaly thing to class different models/archs ....
after talking a bit with other -dev's people feel that a new 'no arch' keyword would do more harm than good ... it's also not good for QC ... i also feel Azarah summed up some good points
