On Fri, Jun 18, 2004 at 11:52:36PM +0200, Dominique Devriese wrote: > Adrian Bunk writes: > > > On Fri, Jun 18, 2004 at 10:29:07PM +0200, Dominique Devriese wrote: > >> ... Clearly, the highest severity that this bug can arguably > >> qualify for is "serious" if and only if Chris Cheney thinks so, and > >> important otherwise. Chris has clearly shown that he did not at > >> the time think so, so I am downgrading this bug to important. It's > >> up to him to change it to serious if he thinks it deserves that. I > >> hope we can now stop playing pingpong with the severity ? > > > As said in the part of the mail you skipped: Your RM reopened a > > similar (grave) bug I sent that covered a similar issue. > > > Chris uploaded a new version of kdelibs 6 days after my bug report. > > > Why did he downgrade it instead of simply fixing the issue via a > > conflict? > > Probably because > 1 adding a conflict to a package because of a bug in another package > is generally the wrong thing to do, even if it may be good as a > workaround in this case
To quote another mail I sent to you in this thread: <-- snip --> Please read the statement of your RM regarding a similar issue in #170385 (in this case it was even clear that the bug was not in the library). <-- snip --> Is it really "the wrong thing to do" if your RM thinks a conflict is required in such cases? > 2 you did not provide a lot of explanation about why it was the > correct thing to do in this case It's the only way to solve this issue. And if the it's unclear, a question might be a better solution than a silent lowering of the severity... > >> > In the sense "must be fixed, before the new kdelibs enters > >> > testing, or apollon in testing will be broken". > >> > >> The only thing that's keeping the new apollon ( which, according to > >> its changelog has the real fix for the problem ) from entering > >> testing is its dependency on kdelibs. Thus, there is little chance > >> that the new kdelibs would enter sarge and the new apollon > >> wouldn't. ... > > > Imagine a new upload of apollon to unstable, a RC bug in apollon, or > > many other reasons like apollon not being built on one architecture. > > Of course, but you have to agree that it won't take ages to fix > something like this in a simple package like apollon. This is where > the difference is with the wine bug you were talking about. It was _exactly the same situation_: Wine in unstable was already fixed at that time. The point of a conflict is to force an upgrade of the application at the same time as the upgrade of the library. > By the way, why do you seem to think that an uninstallable version of > apollon in sarge is better than a version that crashes on startup ? I'm not a big fan of testing, but one positive side of testing is that the way testing works this can't happen [1]. > cheers > domi cu Adrian [1] except for cases of manual interventions of the RM -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed