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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
