Bug 104680 - Improved k3b ebuild, to get rid of `fmt -w`
|
Bug#:
104680
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: kde@gentoo.org
|
Reported By: phreak@gentoo.org
|
|
Component: KDE
|
|
|
URL:
|
|
Summary: Improved k3b ebuild, to get rid of `fmt -w`
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-09-03 00:30 0000
|
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
> 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.
