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.
