k3b uses fmt -w (from coreutils) in global scope, which is really bad. In the latest coreutils (~x86 that is here) `fmt` doesn't even accept the '-w 10000' used in the ebuild. The ebuild tries to avoid this, by using LINGUAS and USE="nls" (which might be a bad idea). Reproducible: Always Steps to Reproduce: # emerge >sys-apps/portage-2.1.0_alpha20050718 # emerge --regen Actual Results: $ emerge -pv k3b These are the packages that I would merge, in order: Calculating dependencies fmt: invalid width: `10000' uniq: write error: Broken pipe fmt: invalid width: `10000' uniq: write error: Broken pipe fmt: invalid width: `10000' uniq: write error: Broken pipe fmt: invalid width: `10000' fmt: invalid width: `10000' fmt: invalid width: `10000' uniq: write error: Broken pipe ...done! [ebuild N ] app-cdr/k3b-0.12.3 Expected Results: [ebuild N ] app-cdr/k3b-0.12.3
Created attachment 67539 [details] k3b-0.12.3.ebuild An improved ebuild, which uses USE=nls, strip-linguas and LINGUAS to determine which languages to install.
Created attachment 67543 [details] k3b-0.12.3.ebuild.diff Diff between k3b from cvs and the improved one ...
> k3b uses fmt -w (from coreutils) in global scope, which is really bad. No alternative at the moment, as it is the case with a lot of other things. > In the latest coreutils (~x86 that is here) `fmt` doesn't even accept the '-w 10000' used in the ebuild. And what (value) does work? > The ebuild tries to avoid this, by using LINGUAS and USE="nls" (which might be a bad idea). Right. It's not acceptable to mix use flags this way. That said: I'd favor it, if we'd fix and unify our localization approaches (nls, LINGUAS, userlocales) some day...
(In reply to comment #3) > And what (value) does work? Maximum thats working here is -w 2500. > Right. It's not acceptable to mix use flags this way. That said: I'd favor it, > if we'd fix and unify our localization approaches (nls, LINGUAS, userlocales) > some day... Why not fix it now, to give others a starting point ?! :)
Err... that LINGUAS portion of MAKE_LANG isn't valid, you can't do that _period_ :) The metadata changes depending on the users environment, that's a major no no.
Bleh, ignore me regarding metadata; curious, what's the reasoning for why it cannot be done within pkg_setup?
dont use 'useq' ... just utilize 'use' ... otherwise, proposed patch looks good in theory
(In reply to comment #6) > Bleh, ignore me regarding metadata; curious, what's the reasoning for why it > cannot be done within pkg_setup? Pure historical... btw.: Would it be possible to have a flag "linguas", which is set when any "linguas_foo" is set? I'd also appreciate if you could have a look at Bug 98425. I'd like to know, if we can exect some "second level slot dependency" support from portage. I'm not sure, if you're already aware of the problem or if a new bug for it makes sense. (In reply to comment #7) > otherwise, proposed patch looks good in theory Mixing two use flags this way is really bad.
maybe, but that isnt going to happen anytime soon, and the current ebuild is a lot more broken than what is proposed here
and generally it doesnt make any sense to have LINGUA set to something non-english and have USE=-nls
(In reply to comment #10) > and generally it doesnt make any sense to have LINGUA set to something > non-english and have USE=-nls It doesn't make sense to have two configuration options for one purpose and no user will expect this usage, because it never was (correctly) never handled this way and is nowhere documented. (In reply to comment #9) > maybe, but that isnt going to happen anytime soon, and the current ebuild is a > lot more broken than what is proposed here What's really broken is fmt as it seems, when you look at comments to the code.
