[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More conflicts data



And... sending it again, to the list this time.
----------------
Hi,

Sorry for the response time, I was on holiday and quite busy.

On Sat, March 24, 2007 04:34, Guillem Jover wrote:
>> I still need to move the conflicts against a specific version of a package
>> to its own page, but things start be look a bit clearer as I split into
various categories.
>>
>> All the data is still available at http://www.imalip.info/debian/
>
> Could you group them by maintainer/uploader?

I will do that.

>> 30% of the conflicts declared in Sid are against packages which are not
referenced in any release since bo. It includes conflicts against
non-i386
>> packages, but I don't believe there are many of these.
>
> Yeah, those should be few, but to be on the safe side, this would have
to be run against all arches.

To be honest, the "no package" category contains so many different cases,
it can hardly be sorted in a non-manual way. I will probably do it anyway.

>> I'm still not sure about what would be a good policy on removing
conflicts, but I guess some would be obvious.
>>
>> Any comment or suggestion is welcome.
>
> As we guarantee an upgrade path from only the previous release
> (oldstable -> stable), and we support for some time oldstable
> (security-wise), to not make backports more difficult, probably it would
make sense to remove only those that affect oldstable-1 and oldstable
once the support is terminated?

Could be sensible, that was more or less what I had in mind originaly.
Considering woody as oldstable-1, that would give a list of 2500 removable
conflicts.

The main annoying problem I see is if package a was in bo and removed in
hamm, and package b conflicts with a. Someone could actually have a
installed and not b, upgrade step by step to lenny, and install b. That
would break :(.

The other complicated bit is transitions happening between releases, such
as the python one. After how many months (years ?) do we consider people
running testing or unstable who haven't made upgrades should sort the
problems by manually removing packages ?

Regis




Reply to: