Re: More conflicts data
Hi,
Back with a bit more...
On Fri, 2007-03-30 at 01:13 +0300, Guillem Jover wrote:
> On Thu, 2007-03-29 at 15:18:07 +0100, Regis Boudin wrote:
> > On Sat, March 24, 2007 04:34, Guillem Jover wrote:
> > > > All the data is still available at http://www.imalip.info/debian/
> > >
> > > Could you group them by maintainer/uploader?
> >
> > I will do that.
>
> Thanks.
Now done. Maybe not the best way, but there are now lists of conflicts
for each Maintainer.
> > > > 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.
Added the checks including all the various official arches.
> You might want to check those as well against:
>
> <http://ftp-master.debian.org/removals.txt>
Will be my next step to do checks...
> > 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 :(.
>
> I'd say this is a general problem in Debian, which includes packages
> w/o security support, etc. I think Ubuntu has some package to
> help in the upgrade with obsolete/dummy packages.
Most of the time, I believe they are in fact transitions, so there
should be an upgrade path to get old versions removed, and we're left
with a harmless dummy package.
By the way, don't we already have tools to track dummy packages ?
> > 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 ?
>
> Hmm do you mean things that broke in unstable/testing and got fixed
> in-between and never got the chance to move to a stable release?
>
> Or for transitions that went into stable (and consequendly to
> oldstable) but we don't know if the user upgraded unstable/testing
> meanwhile?
>
> For the first I'd say one release, for the second the normal criteria
> for oldstable-1 or similar, if people has not updated their
> unstable/testing system for so long, I don't think we are expected to
> support that. (Or did you mean something else?)
I believe it's neither. The good example situation would be the python
transition. python2.3-foo and python2.4-foo appeared after sarge, and
were replaced later by python-foo conflicting with both which then
completely disappeared from the data I've been parsing so far. The same
thing happened with the second C++ ABI transition from libfooc2 to
libfooc2a.
Anyway, the next step is to parse the data about packages removal to
give useful informations about the 2600+ conflicts in the no_package
section.
As usual, if anyone has comments or ideas, they are welcome :)
Regis
Reply to: