severity 354756 important thanks On Wed, Mar 01, 2006 at 10:39:33AM -0500, Mike Furr wrote:
> Steve Langasek wrote: > > Your point is non-obvious to me. A Replaces: w/o Conflicts: makes sense > > only if ownership of files has moved from one package to another, which is > > not the case here since the two versions of the package aren't necessarily > > compatible; a Replaces: w/ Conflicts: is used to indicate that one package > > should be preferred over the other; a Conflicts: alone says that the two > > packages cannot be installed together, without making any claims about which > > one should be installed. Why is the last use the wrong one here? In > > particular, why is it so wrong that it warrants a bug of severity: serious? > I guess I'm arguing that there should be an upgrade path from the "new" > drivers to the "legacy" drivers. This was experience: I have an old > graphics card in this box (TNT2) and had held the "new" drivers to the > last version that supported it (upstream 1.7174). When I saw the legacy > drivers package (using the same upstream 1.7174), I rejoiced that I > would not have to fight with aptitude any more over this. I removed the > old nvidia-kernel-source package and installed the -legacy variant. I > then build a nvidia-kernel-legacy module and tried to install it. Since > it contained the same files as the previously installed nvidia-kernel > module package, dpkg failed as there was no Replaces. Thus to install > it, I would have to remove the module, which would remove the glx > packages and a host of other things which would be a huge PITA. Note > that this would also be the case if I were coming from Sarge with this > graphics card. Well, except that a) using apt to install the new package would automatically handle this upgrade case for you (and there are binary nvidia-kernel-legacy packages in the archive for 2.6.15-1), and b) if you use dpkg for both removing the old package and installing the new one, you don't have to remove the other packages either. So you have a point that this could be improved, but it doesn't look like the current behavior of the package is wrong from a policy compliance perspective. > I believe this path is the most likely. The only time I would go from > legacy => new would be if I upgraded the graphics card. In which case > I'd have to boot w/o X anyway, so it would be more acceptable to have to > remove the graphics drivers/glx libs while upgrading the drivers. > Ideally, I guess the legacy package should Replace the new(<= 1.7174), > but I assume that like versioned Conflicts, this isn't supported? This > way we could also have the new version (>1.7174) Replace the legacy > package.... Versioned conflicts and replaces are both supported. So probably the best option would be Package: nvidia-kernel-legacy-#KVERS# Conflicts: nvidia-kernel-#KVERS# Replaces: nvidia-kernel-#KVERS# (<< 1.0.7664-0) or, pick some other upper cap for the replaces: that seems appropriate. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
