Bugzilla Bug 99403

The kdemultimedia-3.4* ebuilds pull in libmad libraries if the mp3 USE flag is
set. However on mips the libmad library doesn't work and just outputs static, so
we have mad use.mask'ed in our profiles. We for obvious reasons can't mask the
mp3 flag. I cannot keyword kde 3.4 for mips until this is resolved.

Oh, nice. :( Maybe you want to track/comment on Bug 94045 and Bug 98996.

Changing an ebuild that is correct for 99.9% of users for the remaining 0.1% 
does not make much sense. A better solution would be to see if there's a 
version of libmad working (bug #85348 comment #15), or even doing something 
like "!mips? mp3? ( libmad )" in DEPEND. 
 
 

So basically you are saying you would rather put an ugly hack into DEPEND
instead of doing it the proper way and actually using the mad USE flag?  You
see, we put these sorts of things into use.mask so that we *don't* hit problems
like this.  I'm not following your logic here.  In fact, comment #2 basically
comes across as "*yawn* we don't give a shit about mips, go away".  Reminds me
of the response we got when the split kde ebuilds were announced and we objected.

>So basically you are saying you would rather put an ugly hack into DEPEND
instead of doing it the proper way and actually using the mad USE flag?

In this case, yes. You ask why?! Prefixing by !mips? is acceptable in this case
and doesn't harm anyone. But constantly changing use flags is a problem for our
user base and KDE 3.4 is marked stable already. I do not see a big impact on
mips anyways; Either way no mad mips. ;)

Well, I completely disagree.  Otherwise, what is the point of use.mask?  If
every ebuild maintainer where "99% of their users aren't effected" didn't bother
to check use.mask for the various arches before putting deps into their ebuilds,
mips would have quite a mess on their hands.  This is the sort of thing package
maintainers are supposed to pay attention to before making an ebuild stable on
their arch.

You may say that changing USE flags is a problem for kde users.  I say that
fixing a problem now instead of resorting to crappy DEPEND hacks which will just
continue to propagate into the future is a much better idea.  Besides, your
"99%" of users are probably on uber fast x86 or amd64 machines and shouldn't
have any problems recompiling kdemultimedia to fix one USE flag, right? :P

Stephen, the point is that it happened already. And there's no point having the
large majority of users rerefine their use flags (Think about what happens, when
they do emerge --newuse...). I'd even say "no way", if mips or another
architecture would be my favourite niche. Also having an exploding numbers of
use flags, increasing the complexity of Portage (I really have a problem with
the current set of use flags and the lax/missing policy to add new ones!) to
satisfy all the different architectures is neither a solution. Therefore I
openend Bug 98996. Please be a bit pragmatical and don't moan about this "hack"
as if it is meant to stay forever.


>Besides, your "99%" of users are probably on uber fast x86 or amd64 machines
and shouldn't have any problems recompiling kdemultimedia to fix one USE flag,
right? :P

There are enough users without uber fast machines, otherwise there wouldn't be
the recurring demands for binary packages. It's also a question of reliability
not to be forced to rebuild for no reason.

(In reply to comment #6)
>Also having an exploding numbers of
> use flags, increasing the complexity of Portage (I really have a problem with
> the current set of use flags and the lax/missing policy to add new ones!) to
> satisfy all the different architectures is neither a solution.

hellfire ~ # grep mad /usr/portage/profiles/use.*
/usr/portage/profiles/use.desc:mad - Adds support for mad (high-quality mp3
decoder library and cli frontend)

I agree about adding new USE flags, but since mad already existed, why wasn't it
used in the first place?  I'm not asking for a brand new local use that would
only be mips specific.  This is global, and has been for a long time.  For some
architectures, masking USE flags is a necessity.  It is how we get around poorly
programmed stuff that isn't very portable, but ends up being deps in certain
ebuilds.

> Therefore I
> openend Bug 98996. Please be a bit pragmatical and don't moan about this "hack"
> as if it is meant to stay forever.

So then you are saying that it isn't ok to force the "99%" of users to change
their USE flags now, but it will be ok sometime in the future?  Since it isn't
staying around forever of course...  Anyway, I don't see how bug 98996 is going
to fix this problem, because it seems lacking on information.  Are you propsing
a depend.mask of some sort?

> >Besides, your "99%" of users are probably on uber fast x86 or amd64 machines
> and shouldn't have any problems recompiling kdemultimedia to fix one USE flag,
> right? :P
> 
> There are enough users without uber fast machines, otherwise there wouldn't be
> the recurring demands for binary packages. It's also a question of reliability
> not to be forced to rebuild for no reason.

I should have put <sarcasm></sarcasm> tags around that statement.

>I agree about adding new USE flags, but since mad already existed, why wasn't it
used in the first place?

See Bug 94045. Apparently we were too fast. What bothers me that it's not even
noted in the ChangeLog.

>Anyway, I don't see how bug 98996 is going to fix this problem, because it
seems lacking on information.  Are you propsing a depend.mask of some sort?

Thanks for the tip, I assumed it would be natural to extend the use.mask files.

foo       would still mean to mask use flag foo for the specific profile
foo:cat1/pkg1,cat2,pkg2,...      would mask single flag|pkg combinations


>So then you are saying that it isn't ok to force the "99%" of users to change
their USE flags now, but it will be ok sometime in the future? 

No, I said it happened already - past tense. And I don't see a reason changing
it for KDE 3.4.x. 


> I should have put <sarcasm></sarcasm> tags around that statement.

And when you put out the flame thrower it's getting hot and crispy. :)

Look, it's really simple: 
 
- mp3 is the correct flag to use in this case. 
 
- USE flags were never intended to make it easy for arch maintainers to mask 
some package, that's just a side effect. So using mad instead of mp3 is not 
"the proper way". 
 
- any solution is a hack, until bug 98996 is solved. 
 
- It does not make sense that the hack needed to solve this mips-specific 
problem should affect everyone outside mips. 
 
btw: the change is noted in the ChangeLog. 
 

(In reply to comment #9)
> Look, it's really simple: 

You are right, it is really simple. 

> - mp3 is the correct flag to use in this case.

So using the mp3 USE flag for libmad when a mad USE flag *already* exists is the
correct thing?  Uhh, no.  Swegener even pointed out this would screw mips in bug
#94045 before any of this happened, yet you went through with it anyway.  Way to
pay attention.

> - USE flags were never intended to make it easy for arch maintainers to mask 
> some package, that's just a side effect. So using mad instead of mp3 is not 
> "the proper way".

Note that putting mad in use.mask isn't the only way this is masked.  I also
added -mips keywords to libmad and anything that depends directly on it.

> - any solution is a hack, until bug 98996 is solved. 

Well, it certainly won't be solved if nobody but carlo is CC'd on it.

> - It does not make sense that the hack needed to solve this mips-specific 
> problem should affect everyone outside mips. 

So basically, you don't care about arch teams of which you have nothing to do? 
Typical...

> btw: the change is noted in the ChangeLog. 

So what?  It is still wrong.  

> So using the mp3 USE flag for libmad when a mad USE flag *already* exists is
the correct thing? 

The direction is correct imho, but...

Gregorio, I also noticed this a few times, when you just removed a package from
tree. I did not say a word, since I always appreciate seeing a upstream
unmaintained package r.i.p.. We have policies for this sort of changes: Things
like the change mad -> mp3 should go through the gentoo-dev ml to avoid such
situations. Same before deleting packages: Sending an email, asking if anyone is
interested to maintain the package, is policy as well as a wait period of iirc
30 days before removal (the mostly used time frame is a week, though).


>Well, it certainly won't be solved if nobody but carlo is CC'd on it.

Hm? I assume everyone interested in portage development is on the dev-portage
alias... Again - it happened. Please calm down. This is a nothing we can't
handle, even if you don't like it. ;p There are really a number of bigger issues
with portage.

Yeah, I'm really sorry if I gave the impression of trying to annoy people just 
for the sake of annoying, that surely was not my intention (I really hate to 
annoy people). I will try to rephrase what I think to make it clearer: 
 
I strongly believe that *from the user point of view* being presented with the 
'mp3' flag instead of 'mad' is many order of magnitude more convenient, 
because everyone knows what mp3 support is, and every user is able to tell in 
a fraction of a second whether he wants to enable mp3 support or not. 
On the other side, the large majority of users do not know what libmad is (I 
didn't know it a couple of years ago). 
 
For this reason, I believe that presenting the mad flag instead of mp3 does 
annoy users, in the sense that it makes a choice confusing when it could be 
very clear. 
 
Note also that I didn't push for the introduction of the mp3 flag, it was 
introduced by the sound team some time ago. 
 
So I'm just trying to make life easier to a lot of users, really, I do not 
have anything against mips. 
 

Is the issue fixed? Can we close this bug?

If this is still an issue, it applies to kde-base/kdemultimedia-kioslaves, but
seeing as most of the mentioned bugs are fixed, it doesn't look like it is.

It was already discussed in the past, and using mp3 useflag for libmad
dependency, when libmad is the only mp3 decoder available for a given package,
was the accepted way to go (even if I disagree, but that's beside the point).

Now we have package.use.mask so the issue of masking is also resolved, so I'll
close this bug as RESO WONTFIX. If you had anything more to say about that, you
could have used the various discussions that I tried to steer in the past.