On Sun, Feb 03, 2008 at 10:58:03PM +0100, Rafael Laboissiere wrote: > > In practice, most of the reverse-depends of octave2.9 have versioned > > dependencies on octave2.9, so most of these will refuse to accept octave3.0 > > as a replacement. And octave3.0 also *conflicts* with octave2.9, so they're > > not exactly co-installable either. Something looks very wrong here.
> I am revisiting this issue now and need some advice from you. The goal of > having octave3.0 conflicting/replacing/providing octave2.9 is to ensure that > users having octave2.9 installed will be upgraded to octave3.0. This is > correct from the upstream point of view, because the 2.9.* series of Octave > were considered as pre-releases of Octave 3.0.0 (I know, I know, we should > have used octave3.0 as the source package name to start with...) > Now, would just conflicts/replaces achieve that goal? To the best of my knowledge, none of these configurations achieve that goal. While there's lore among Debian developers to the effect that "Conflicts/Replaces" will trigger the package manager to pull in the new package automatically as a replacement for the obsolete package, I have never seen this happen in practice with any of the frontends. The only two configurations that I know to achieve this purpose are: - create a dummy package under the old package name, which depends on the new package name - keep the old package name for the new version of the software 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. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
