Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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, it’s become one of the checks we
do for stabilizing a package. You can look at some of the other packages we’ve
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.