arm, mips, sh please test and keyword hunspell. Please enable only hunspell USE flag when testing. Also please mask zemberek USE flag in your arches.
(In reply to comment #0) > Also please mask zemberek USE flag in your arches. This applies to all the arches in CC.
(In reply to comment #0) > Also please mask zemberek USE flag in your arches. Any reason to mask it instead of keywording it ?
(In reply to comment #2) > (In reply to comment #0) > > Also please mask zemberek USE flag in your arches. > > Any reason to mask it instead of keywording it ? > I as zemberek-server developer don't support anything other than x86 and amd64. And Java is not supported on all those. See keywords of virtual/jdk-1.{5,6}.0
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > Also please mask zemberek USE flag in your arches. > > > > Any reason to mask it instead of keywording it ? > > > > I as zemberek-server developer don't support anything other than x86 and amd64. > And Java is not supported on all those. See keywords of virtual/jdk-1.{5,6}.0 Then I should put in use.mask "I'm lazy, it's not supported" as mask reason ? :) (since on bsd, even if very slacking and late, java is supported)
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #0) > > > > Also please mask zemberek USE flag in your arches. > > > > > > Any reason to mask it instead of keywording it ? > > > > > > > I as zemberek-server developer don't support anything other than x86 and amd64. > > And Java is not supported on all those. See keywords of virtual/jdk-1.{5,6}.0 > > > Then I should put in use.mask "I'm lazy, it's not supported" as mask reason ? > :) > (since on bsd, even if very slacking and late, java is supported) > As developer I mean "upstream". I have no resources to test it on BSD. Feel free to put "Not supported by upstream"
(In reply to comment #5) > As developer I mean "upstream". I have no resources to test it on BSD. Feel > free to put "Not supported by upstream" Yes, but my point was more that I want a valid reason to mask something; and me being lazy to test/keyword a package isn't a valid one ;) Usually not having ressources to test on some weird arch is the reason why someone asks for keywording ^^ If you really don't want other keywords for zemberek-server, please put -* in its keywords (though I'm not sure how valid it is) and at least a comment about it.
(In reply to comment #6) > (In reply to comment #5) > > As developer I mean "upstream". I have no resources to test it on BSD. Feel > > free to put "Not supported by upstream" > > Yes, but my point was more that I want a valid reason to mask something; and me > being lazy to test/keyword a package isn't a valid one ;) > Usually not having ressources to test on some weird arch is the reason why > someone asks for keywording ^^ > > If you really don't want other keywords for zemberek-server, please put -* in > its keywords (though I'm not sure how valid it is) and at least a comment about > it. > Added testcase for zemberek-server in http://overlays.gentoo.org/proj/java/browser/testcases/app-text/zemberek-server. Please go ahead.
So you want to add a few lines in the package.use.mask of *all* those arches (10 files) instead of just the global use.mask, and the local unmasking for x86 and amd64 (3 files)? And why would I want that in HPPA's profile, exactly? :)
(In reply to comment #8) > So you want to add a few lines in the package.use.mask of *all* those arches > (10 files) instead of just the global use.mask, and the local unmasking for > x86 and amd64 (3 files)? And why would I want that in HPPA's profile, exactly? > :) > Done. Sorry for the confusion. arm, mips, sh: Still need keywording for hunspell.
Hey wait, to me if zemberek has to be keyworded only for x86 and amd64, it should have -* in keywords and masking it in base the way to go. If it has to/can be supported on all java supported arches, then imho it should be treated the same way as the java useflag which is afaik not masked in base but masked for java-unsupported arches.
(In reply to comment #10) > Hey wait, to me if zemberek has to be keyworded only for x86 and amd64, it > should have -* in keywords and masking it in base the way to go. -* is hardly ever done nowadays. It's only really needed for packages that will horribly break a system if it's deployed on the wrong arch. Any user sticking 'app-text/zemberek-server **' in package.keywords would quickly find out that he'd have to port virtual/jdk as well. :) > If it has to/can be supported on all java supported arches, then imho it should > be treated the same way as the java useflag which is afaik not masked in base > but masked for java-unsupported arches. It's a matter of efficiency, I like to think. Why bother each arch to get an entry in an arch profile file when you can keyword ~x86 and ~amd64 yourself and then perhaps a ppc developer can unmask the USE flag in due time too. There are no strict rules about when to unmask/mask globally/locally. I certainly wouldn't agree that ppc couldn't get their keyword in - maybe if you declared as upstream (perhaps in a license restricting your software) that app-text/zemberek-server shouldn't touch ppc, that would work, but it would still go against some basic Gentoo policy.
~arm/~sh done
What is preventing mips from keywording this?
~mips added to 1.6.0, tested with gedit[spell]. Nuked older versions than 1.6.0 as well.
