Re: Question about obsolete Conflicts
Hi,
On Tue, March 6, 2007 06:34, Bart Martens wrote:
> On Tue, 2007-03-06 at 01:43 +0000, Regis Boudin wrote:
>> Playing around with dependencies trees, I noticed there are quite a few
>> obsolete Conflicts fields in the archive. Would it be worth starting a
>> bit of cleanup after Etch is released ? I think having the archive
>> cleaner from this point of view might not be a bad thing.
>
> Cleaning is good. Note that there's a difference between "old" and
> "obsolete".
I know, that's why i used this word :)
> Some old conflicts can still be useful for users with long
> upgrade paths, with some old packages still installed. Also, some
> conflicts are against packages not in the Debian repository at all, and
> also those conflicts can be useful.
The upgrade path aspect was obvious to me, I mainly wanted to bring the
subject and see if I was missing a point first.
>> I mean... There are things like the 98 packages which still conflict
>> with a pre-woody suidmanager, or apache with apache-modules which was
>> removed from the archive 9 years ago,
>
> Maybe the maintainers have good reasons, no idea.
My guess about the reason would be that the field is set manually and
almost nobody ever cares about cleaning it up when is becomes useless.
>> Shouldn't there be some sort of best practice or recommandation
>> somewhere about cleaning this field when it becomes useless ?
>
> If it's not already mentioned in debian-policy, then it could be added
> that obsolete/duplicate/redundant conflicts should be
> simplified/removed.
My idea was something like this situation :
woody has package a.
sarge has package b, which conflicts with package a not in woody (either
because the package doesn't exist at all or versionned conflict).
etch is in the same situation as sarge.
the conflict can be removed in lenny.
It leaves a gap of 2 releases and could only be a problem if someone tries
to upgrade directly from n to n+3. n->n+1->n+3 and n->n+2->n+3 would still
work on this side. Since we only support upgrade from n to n+1 AIUI, the
gap could be tightened in theory, but it's probably a good idea not to be
to strict.
> I think that it's difficult to find an approach for an efficient
> all-packages review about old/obsolete conflicts.
Well, in my idea it would only be suggested, there are lots of reasons to
keep a conflict (backports for instance). But I believe in most cases it
could be removed. And building a list of non-possible conflicts per
distribution can be made and compared.
>>
>> Any comment to tell me whether I got it wrong or not is welcome :)
>
> Not wrong. Just a matter of tuning the scope a bit. :)
I guess my scope was right, I just didn't write everything I had in mind
because some bits were obvious to me. The sort of thing that can happen
when one send an email at 1h43 because he can't sleep :)
Regis
Reply to: