An easy one. No problematic dependencies this time.
* checking 99 files for package collisions existing file /usr/share/mimelnk/application/x-mplayer2.desktop is not owned by this package main kmplayer # equery b /usr/share/mimelnk/application/x-mplayer2.desktop [ Searching for file(s) /usr/share/mimelnk/application/x-mplayer2.desktop in *... ] media-video/kaffeine-0.7.1 (/usr/share/mimelnk/application/x-mplayer2.desktop)
Known issue, bug 76933. But this shouldn't stop you marking it stable.
I'm sorry but collision protection bugs are a detriment for stable users. Yes, this does prevent me from marking it stable and other members agree as well. Our stable base is meant to be just that, so something that is unable to install because of a feature that stable users have a posibility of enabling simply doesn't work. In the case of security bugs, yes, sometimes we have to overlook that, but this is not such an instance.
The current stable version has the same problem. Users won't have problems with upgrading the package because if two packages still own the same file they are considered both, the problem is only with new installs, the same of the current version. You should also consider the quantity of fixes against a minor glitch currently present in the stable version. And blame who marked it stable in the first time if you really need to :)
How about just fixing the "known bug" and only then proceed to stabilization? I agree with Chris that this stops us from doing the stabilization. Imagine a new (to Gentoo) user trying to install a stable package, and failing - that will not leave him with a good impression of the distribution.
This is ridiculous. It's not a regression and that stable implies collision-protect enabled is something I'll ask you to discuss on the gentoo-dev mailing list. From my point of view it is a nice tool to find such bugs, but we do not live in a perfect world. Or to put it another way: I found it more important to e.g. bring the deprecation of libungif forward - started by you Chris, not having the balls to do whole the annoying work (and that's not the first time I noticed this behaviour from your side), than deaing with this minor issue. I'm quite sure I sent an email upstream about this issue, but need to look up the pile of emails, if I got an answer (Unfortunately I don't hav the time to read everything and too much slips through.), but I assume this has even more implications with having different .desktop in the kde directory and /usr, but I simply had not enough time tolook into it. I'll have the issue on my list, but it's pretty much on the bottom. So getting picky on this issue is really pissing me off. If it makes you feel better you can add RESTRICT="collision-protect" to the ebuild, otherwise stop complaining and mark it stable, please.
> This is ridiculous. Your response was a bit. > It's not a regression and that stable implies > collision-protect enabled Devs are *supposed* to run with it enabled. Supposed to run with a lot of QA options enabled, specifically so that they hit the initial mess and clean it up, rather then users hitting open borkage. Doesn't matter if it's a regression or not, it still is a bug. >started by you Chris, not having the balls to >do whole the annoying work (and that's not the first time I noticed this >behaviour from your side), than deaing with this minor issue. Leave this crap out of bugzilla. It's course, rude, and (frankly) an ad hominem attack rather then dealing with the request from _two_ devs who you disagree with. You stated you would fix this in the other bug, well, get cracking. >So getting picky on this issue is really pissing me off. If it makes you feel >better you can add RESTRICT="collision-protect" to the ebuild, otherwise stop >complaining and mark it stable, please. RESTRICT="collision-protect" doesn't exist. You add that to the tree and QA along with a pissed of portage dev or two come looking for ya. This isn't a huge thing, just figure out a fix rather then warring, alright? Doesn't matter if it pisses you off, the request _is_ valid (and you've acknowledged it in the other bug), so do something about it.
(In reply to comment #7) > Devs are *supposed* to run with it enabled. Bite me, I don't have. > Leave this crap out of bugzilla. It's course, rude, and (frankly) an ad > hominem attack rather then dealing with the request from _two_ devs who you > disagree with. You stated you would fix this in the other bug, well, get > cracking. And it was meant to be rude. Feel free to take it to devrel, if your feelings are hurt in place of Chris's. > This isn't a huge thing, just figure out a fix rather then warring, alright? > Doesn't matter if it pisses you off, the request _is_ valid (and you've > acknowledged it in the other bug), so do something about it. I disagree that this request is valid.
(In reply to comment #8) > I disagree that this request is valid. Carlo, you're the first developer (sure it won't be the last but..) that has had an issue with a request to fix a collision before we mark it stable. Since the x86 team has gotten its stuff together, it
(In reply to comment #8) > I disagree that this request is valid. Carlo, you're the first developer (sure it won't be the last but..) that has had an issue with a request to fix a collision before we mark it stable. Since the x86 team has gotten its stuff together, its become one of the checks we do for stabilizing a package. You can look at some of the other packages weve asked for these fixes before stabilizing, such as natatalk or the recently arched app-science packages. Stable like the name entails should not only run cleanly without bugs, but should install cleanly whatever a user might use for flags. A collision is not a clean install in this case. We are overwriting a file that belongs to someone else; would you want that to happen with say libc.so.6?
At this point, I don't care if the two block each other until a real fix can be made. The issue has to be addressed before we mark another version stable though.
cvs update and mark stable please.
x86 stable
tested on ppc works for me
ppc stable
Stable on amd64, closing as we are the last arch.
