Re: linux-2.6_2.6.12-2_i386.changes REJECTED
On Wed, 2005-08-10 at 07:50 +0200, Sven Luther wrote:
> On Tue, Aug 09, 2005 at 05:21:37PM -0600, dann frazier wrote:
> > On Tue, 2005-08-09 at 21:04 +0200, Bastian Blank wrote:
> > > On Tue, Aug 09, 2005 at 03:11:37PM +0900, Horms wrote:
> > > > On Tue, Aug 09, 2005 at 07:56:13AM +0200, Bastian Blank wrote:
> > > > > This is not an appropriate upgrade path as this headers don't ask apt to
> > > > > install the new package.
> > > > Even with the appropriate Replaces/Conflicts/Provides?
> > >
> > > Okay, we have kernel-image-$foo installed. Now we get a new package:
> > > | Package: linux-image-$foo
> > > | Replaces: kernel-image-$foo
> > > | Conflicts: kernel-image-$foo
> > > | Provides: kernel-image-$foo
> > >
> > > What does apt do?
> >
> > If apt sees that foo is installed on a system and
> > foo 2.0.1-1 is available
> > bar 1.0-1 is available, and provides/conflicts/replaces foo
> >
> > An apt-get dist-upgrade should remove foo and install bar.
> >
> > See http://www.debia.org/doc/debian-policy/ch-relationships.html -
> > section 7.5.2
>
> Yeah, but kernel-latest provided version numbers starting with 100, so ...
The version number doesn't appear to matter.
I created a bogus deb called goodbye that provides/conflicts/replaces
hello. I tried giving it a version < the installed hello, and a version
> than the installed hello. In both cases, an apt-get dist-upgrade did
not automatically pull in goodbye. In both cases, an apt-get install
goodbye did remove hello.
So; Replaces isn't enough of a hint to make this transition happen
automatically. I looked at ssh, and it uses a transititional package as
well.
Anyway; here's another suggestion. Since binary packages don't have to
have the same version as the source package, how about we give the
transitional packages a large version for now. After etch, we can drop
these packages and go back to all packages having the same (non-epoched)
version.
Reply to: