Debian Bug report logs - #428783
linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 14 Jun 2007 08:40:46 +0200

Package: linux-latest-2.6
Version: 2.6.21-4
Severity: wishlist

It would be great if we could have a mechanism to avoid installing a newer
kernel if the packaged modules that the user has installed are not yet
available. A simple example: I have 2.6.18-5 with the corresponding
kqemu-modules 2.6.18-5.

Yesterday I upgraded to sid and linux-image-2.6-686 pulled the new 2.6.21
kernel.  However there's no kqemu-modules for 2.6.21 and thus I lost
support during the upgrade even though I have kqemu-modules-2.6-686
installed.

My suggestion to solve this is to use the new "Breaks" field as soon as
it's introduced in dpkg (it's planned in the next dpkg upload,
apt does already support it).

linux-image-2.6-686 in version 2.6.21+7 would be marked as breaking
the old versions of packages like kqemu-modules-2.6-686.

Package: linux-image-2.6-686
Breaks: kqemu-modules-2.6-686 (<< 2.6.21+7), unionfs-modules-2.6-686 (<<
2.6.21+7), ...

That way the package manager has a clear hint on when it can safely
proceed with the upgrade.

However when you do this, you must also decide to regularly update the
linux-modules-{contrib,extra} packages. Of course, you should only list in
the Breaks field the packages that are autobuilt. Those that are only created
by the user with modules-assistant shouldn't be listed other the upgrade
will never happen (unless the user is clever enough to do it by himself).

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <luther@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 428783@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 14 Jun 2007 10:08:10 +0200

On Thu, Jun 14, 2007 at 08:40:46AM +0200, Raphael Hertzog wrote:
> Package: linux-latest-2.6
> Version: 2.6.21-4
> Severity: wishlist
> 
> It would be great if we could have a mechanism to avoid installing a newer
> kernel if the packaged modules that the user has installed are not yet
> available. A simple example: I have 2.6.18-5 with the corresponding
> kqemu-modules 2.6.18-5.
> 
> Yesterday I upgraded to sid and linux-image-2.6-686 pulled the new 2.6.21
> kernel.  However there's no kqemu-modules for 2.6.21 and thus I lost
> support during the upgrade even though I have kqemu-modules-2.6-686
> installed.
> 
> My suggestion to solve this is to use the new "Breaks" field as soon as
> it's introduced in dpkg (it's planned in the next dpkg upload,
> apt does already support it).
> 
> linux-image-2.6-686 in version 2.6.21+7 would be marked as breaking
> the old versions of packages like kqemu-modules-2.6-686.
> 
> Package: linux-image-2.6-686
> Breaks: kqemu-modules-2.6-686 (<< 2.6.21+7), unionfs-modules-2.6-686 (<<
> 2.6.21+7), ...
> 
> That way the package manager has a clear hint on when it can safely
> proceed with the upgrade.
> 
> However when you do this, you must also decide to regularly update the
> linux-modules-{contrib,extra} packages. Of course, you should only list in
> the Breaks field the packages that are autobuilt. Those that are only created
> by the user with modules-assistant shouldn't be listed other the upgrade
> will never happen (unless the user is clever enough to do it by himself).

This is why i proposed instead to handle the kernel packages otherwise,
outside the normal kernel infrastructure.

We would have a kernel part of the archive, which would be independent
from the normal stable/testing/unstable/experimental setup.

In it, we would have a per kernel-abi version sub hierarchy, which would
contain all modules and other kernel related stuff (even .udebs), so
there would *NEVER* be this kind of breakage, nor a breakage of the
netboot d-i images, since we would always have a given abi available.

Then, we could simply extract from this pools the needed packages to go
in a given distribution, either into unstable (once all dependents are
built, and we are happy with the general non-buggyness), or migrated to
testing, or stable.

This would also make building stable point-release with upgraded kernels
much easier.

If in addition, we separate the d-i image between the kernel-related
part and the non-kernel related part, we can easily, without big
recompilation, produce new images with any of these kernels.

I know that trying to push these ideas is what landed me in the current
mess, but it is what makes the most sense, it is an elegant and clean
solution to all these and related problems, so i ask you to consider it
by itself, instead of rejecting it because it comes from me.

Friendly,

Sven Luther

Message #20 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 14 Jun 2007 12:37:20 +0200

Hi,

On Thu, 14 Jun 2007, Sven Luther wrote:
> This is why i proposed instead to handle the kernel packages otherwise,
> outside the normal kernel infrastructure.
> 
> We would have a kernel part of the archive, which would be independent
> from the normal stable/testing/unstable/experimental setup.
> 
> In it, we would have a per kernel-abi version sub hierarchy, which would
> contain all modules and other kernel related stuff (even .udebs), so
> there would *NEVER* be this kind of breakage, nor a breakage of the
> netboot d-i images, since we would always have a given abi available.

There's no real breakage and it's limited to sid anyway, for the time
between the upload of linux-2.6 and linux-modules-{contrib,extra}. Both
those packages are the responsibility of the kernel team, so it's just a
matter of coordination inside the kernel team.

I don't see the benefit of an extra archive, it would require changes in
the buildd to get this archive autobuilt. Furthermore it would lead to
less user testing since it's outside of unstable and we don't really want
that.

My suggestion takes into consideration the fact that the uploads of
linux-2.6 and linux-modules-{contrib,extra} are not synchronized (because
it's difficult to get all the external modules to build) and proposes a
simple mechanism to make sure that the user notices this
non-synchronization instead of being silently bitten by it.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Message #25 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Sven Luther <luther@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 14 Jun 2007 13:05:54 +0200

On Thu, Jun 14, 2007 at 12:37:20PM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 14 Jun 2007, Sven Luther wrote:
> > This is why i proposed instead to handle the kernel packages otherwise,
> > outside the normal kernel infrastructure.
> > 
> > We would have a kernel part of the archive, which would be independent
> > from the normal stable/testing/unstable/experimental setup.
> > 
> > In it, we would have a per kernel-abi version sub hierarchy, which would
> > contain all modules and other kernel related stuff (even .udebs), so
> > there would *NEVER* be this kind of breakage, nor a breakage of the
> > netboot d-i images, since we would always have a given abi available.
> 
> There's no real breakage and it's limited to sid anyway, for the time
> between the upload of linux-2.6 and linux-modules-{contrib,extra}. Both
> those packages are the responsibility of the kernel team, so it's just a
> matter of coordination inside the kernel team.
> 
> I don't see the benefit of an extra archive, it would require changes in
> the buildd to get this archive autobuilt. Furthermore it would lead to
> less user testing since it's outside of unstable and we don't really want
> that.
> 
> My suggestion takes into consideration the fact that the uploads of
> linux-2.6 and linux-modules-{contrib,extra} are not synchronized (because
> it's difficult to get all the external modules to build) and proposes a
> simple mechanism to make sure that the user notices this
> non-synchronization instead of being silently bitten by it.

So, you solve only your own problem, instead of seeing the problem in
its globality.

Friendly,

Sven Luther

Message #30 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 14 Jun 2007 17:47:09 -0700

On Thu, Jun 14, 2007 at 08:40:46AM +0200, Raphael Hertzog wrote:
> It would be great if we could have a mechanism to avoid installing a newer
> kernel if the packaged modules that the user has installed are not yet
> available. A simple example: I have 2.6.18-5 with the corresponding
> kqemu-modules 2.6.18-5.

> Yesterday I upgraded to sid and linux-image-2.6-686 pulled the new 2.6.21
> kernel.  However there's no kqemu-modules for 2.6.21 and thus I lost
> support during the upgrade even though I have kqemu-modules-2.6-686
> installed.

> My suggestion to solve this is to use the new "Breaks" field as soon as
> it's introduced in dpkg (it's planned in the next dpkg upload,
> apt does already support it).

> linux-image-2.6-686 in version 2.6.21+7 would be marked as breaking
> the old versions of packages like kqemu-modules-2.6-686.

> Package: linux-image-2.6-686
> Breaks: kqemu-modules-2.6-686 (<< 2.6.21+7), unionfs-modules-2.6-686 (<<
> 2.6.21+7), ...

> That way the package manager has a clear hint on when it can safely
> proceed with the upgrade.

> However when you do this, you must also decide to regularly update the
> linux-modules-{contrib,extra} packages. Of course, you should only list in
> the Breaks field the packages that are autobuilt. Those that are only created
> by the user with modules-assistant shouldn't be listed other the upgrade
> will never happen (unless the user is clever enough to do it by himself).

My two objections to this are scalability, and lack of comprehensiveness.
It's not scalable because it means the maintainers of the linux-latest-2.6
package have to centrally keep track of every package in the archive
providing a module metapackage; and it's not comprehensive because you say
at the end that you only want it to list packages that are autobuilt.

Why would it not be sufficient for the metapackages to each depend on the
corresponding linux-image package?  That eliminates the need for a central
registry of such packages.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #35 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Fri, 15 Jun 2007 08:19:51 +0200

On Thu, 14 Jun 2007, Steve Langasek wrote:
> My two objections to this are scalability, and lack of comprehensiveness.
> It's not scalable because it means the maintainers of the linux-latest-2.6
> package have to centrally keep track of every package in the archive
> providing a module metapackage; and it's not comprehensive because you say
> at the end that you only want it to list packages that are autobuilt.

Well, the fact that I restrict it to auto-built package is precisely a
compromise in favor of scalability. Auto-built packages are already
centralized in linux-modules-* and it should be doable to automate this
process much like the rest is already automated.

> Why would it not be sufficient for the metapackages to each depend on the
> corresponding linux-image package?  That eliminates the need for a central
> registry of such packages.

You could be right... do you mean something like this?

Package: <something>-modules-2.6-686
Depends: linux-image-2.6-686 (= 2.6.21+7)

This should give the same behaviour indeed. The modules meta-package would
be broken when the linux-image-2.6 metapackages are upgraded
unsynchronized.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Message #40 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Fri, 15 Jun 2007 01:27:20 -0700

On Fri, Jun 15, 2007 at 08:19:51AM +0200, Raphael Hertzog wrote:
> On Thu, 14 Jun 2007, Steve Langasek wrote:
> > My two objections to this are scalability, and lack of comprehensiveness.
> > It's not scalable because it means the maintainers of the linux-latest-2.6
> > package have to centrally keep track of every package in the archive
> > providing a module metapackage; and it's not comprehensive because you say
> > at the end that you only want it to list packages that are autobuilt.

> Well, the fact that I restrict it to auto-built package is precisely a
> compromise in favor of scalability. Auto-built packages are already
> centralized in linux-modules-*

No, they aren't.  Some of them are, but there's nothing prohibiting other
maintainers from uploading their own kernel module packages.

> > Why would it not be sufficient for the metapackages to each depend on the
> > corresponding linux-image package?  That eliminates the need for a central
> > registry of such packages.

> You could be right... do you mean something like this?

> Package: <something>-modules-2.6-686
> Depends: linux-image-2.6-686 (= 2.6.21+7)

> This should give the same behaviour indeed. The modules meta-package would
> be broken when the linux-image-2.6 metapackages are upgraded
> unsynchronized.

Hmm; I guess I meant

  Depends: linux-image-2.6-686 (>= 2.6.21), linux-image-2.6-686 (<< 2.6.22)

but I realize now that breaks when the ABI changes within an upstream kernel
revision.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #45 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Fri, 15 Jun 2007 10:46:04 +0200

On Fri, 15 Jun 2007, Steve Langasek wrote:
> > This should give the same behaviour indeed. The modules meta-package would
> > be broken when the linux-image-2.6 metapackages are upgraded
> > unsynchronized.
> 
> Hmm; I guess I meant
> 
>   Depends: linux-image-2.6-686 (>= 2.6.21), linux-image-2.6-686 (<< 2.6.22)
> 
> but I realize now that breaks when the ABI changes within an upstream kernel
> revision.

Indeed, and the version of the metapackages doesn't include an explicit
reference to the ABI. IMO it should, then we could do:
Depends: linux-image-2.6-686 (>= 2.6.21-1), linux-image-2.6-686 (<< 2.6.21-2)

Currently you have to lookup the changelog of linux-image-2.6-686 to know
the ABI it corresponds to, which is somehow inconvenient.

BTW, the version numbers in the changelog doesn't correspond to the
version numbers of the generated package. While this is allowed, its there
a compelling reason to do so in this case?

$ zless /usr/share/doc/linux-image-2.6-686/changelog.gz
linux-latest-2.6 (7) unstable; urgency=low

  * Update to 2.6.21-1.
  * Remove etch transition packages.

 -- Bastian Blank <waldi@debian.org>  Tue, 29 May 2007 14:26:20 +0200
[...]
$ dpkg -l linux-image-2.6-686 | grep ^ii
ii  linux-image-2.6-6 2.6.21+7          Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Message #50 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Tue, 26 Jun 2007 12:52:12 -0700

On Fri, Jun 15, 2007 at 10:46:04AM +0200, Raphael Hertzog wrote:
> On Fri, 15 Jun 2007, Steve Langasek wrote:
> > > This should give the same behaviour indeed. The modules meta-package would
> > > be broken when the linux-image-2.6 metapackages are upgraded
> > > unsynchronized.

> > Hmm; I guess I meant

> >   Depends: linux-image-2.6-686 (>= 2.6.21), linux-image-2.6-686 (<< 2.6.22)

> > but I realize now that breaks when the ABI changes within an upstream kernel
> > revision.

> Indeed, and the version of the metapackages doesn't include an explicit
> reference to the ABI. IMO it should, then we could do:
> Depends: linux-image-2.6-686 (>= 2.6.21-1), linux-image-2.6-686 (<< 2.6.21-2)

This seems like a good idea to me.  What does the rest of the kernel team
think?

> BTW, the version numbers in the changelog doesn't correspond to the
> version numbers of the generated package. While this is allowed, its there
> a compelling reason to do so in this case?

> $ zless /usr/share/doc/linux-image-2.6-686/changelog.gz
> linux-latest-2.6 (7) unstable; urgency=low

>   * Update to 2.6.21-1.
>   * Remove etch transition packages.

>  -- Bastian Blank <waldi@debian.org>  Tue, 29 May 2007 14:26:20 +0200
> [...]
> $ dpkg -l linux-image-2.6-686 | grep ^ii
> ii  linux-image-2.6-6 2.6.21+7          Linux kernel 2.6 image on PPro/Celeron/PII/PIII/P4

Dunno.  I don't see a compelling reason not to, either?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #55 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Raphael Hertzog <hertzog@debian.org>, 428783@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Tue, 26 Jun 2007 23:14:24 +0200

On Fri, Jun 15, 2007 at 10:46:04AM +0200, Raphael Hertzog wrote:
> Indeed, and the version of the metapackages doesn't include an explicit
> reference to the ABI. IMO it should, then we could do:
> Depends: linux-image-2.6-686 (>= 2.6.21-1), linux-image-2.6-686 (<< 2.6.21-2)

2.6.21-1 <= 2.6.21-1-1 <= 2.6.21-2? I doubt it. And the linux-2.6
version also don't describe the abi.

> Currently you have to lookup the changelog of linux-image-2.6-686 to know
> the ABI it corresponds to, which is somehow inconvenient.

No, the depends clearly stats which abi this is.

> BTW, the version numbers in the changelog doesn't correspond to the
> version numbers of the generated package. While this is allowed, its there
> a compelling reason to do so in this case?

Otherwise the linux version would complete go away.

Bastian

-- 
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
		-- McCoy, "The Ultimate Computer", stardate 4731.3

Message #60 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Bastian Blank <waldi@debian.org>

Cc: 428783@bugs.debian.org, Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Wed, 27 Jun 2007 08:56:07 +0200

On Tue, 26 Jun 2007, Bastian Blank wrote:
> On Fri, Jun 15, 2007 at 10:46:04AM +0200, Raphael Hertzog wrote:
> > Indeed, and the version of the metapackages doesn't include an explicit
> > reference to the ABI. IMO it should, then we could do:
> > Depends: linux-image-2.6-686 (>= 2.6.21-1), linux-image-2.6-686 (<< 2.6.21-2)
> 
> 2.6.21-1 <= 2.6.21-1-1 <= 2.6.21-2? I doubt it. 

The dash induces the comparison wrong... but that can be solved by
introducing explicitely the debian revision in all versions numbers.

2.6.21-1-0 <= 2.6.21-1-1 <= 2.6.21-2-0

> And the linux-2.6 version also don't describe the abi.

What do you mean?

linux-latest-2.6 doesn't include the ABI in the version number currently,
but that's easy to solve since you have to update that package anyway
every time the ABI changes...

> > Currently you have to lookup the changelog of linux-image-2.6-686 to know
> > the ABI it corresponds to, which is somehow inconvenient.
> 
> No, the depends clearly stats which abi this is.

Right.

> > BTW, the version numbers in the changelog doesn't correspond to the
> > version numbers of the generated package. While this is allowed, its there
> > a compelling reason to do so in this case?
> 
> Otherwise the linux version would complete go away.

Why can't you put the linux version in the changelog itself?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Message #65 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Bastian Blank <waldi@debian.org>, 428783@bugs.debian.org

Cc: Raphael Hertzog <hertzog@debian.org>

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Wed, 27 Jun 2007 11:53:17 -0700

On Tue, Jun 26, 2007 at 11:14:24PM +0200, Bastian Blank wrote:
> On Fri, Jun 15, 2007 at 10:46:04AM +0200, Raphael Hertzog wrote:
> > Indeed, and the version of the metapackages doesn't include an explicit
> > reference to the ABI. IMO it should, then we could do:
> > Depends: linux-image-2.6-686 (>= 2.6.21-1), linux-image-2.6-686 (<< 2.6.21-2)

> 2.6.21-1 <= 2.6.21-1-1 <= 2.6.21-2? I doubt it.

Raphaël addressed this.

> And the linux-2.6 version also don't describe the abi.

Indeed, but in that case the information is encoded in the package name
instead; there's no reason to encode it again in the version number.

> > Currently you have to lookup the changelog of linux-image-2.6-686 to know
> > the ABI it corresponds to, which is somehow inconvenient.

> No, the depends clearly stats which abi this is.

There is no way to express that a module meta package depends on "this ABI
version of module foo, and any linux-image-2.6-$flavor that depends on this
ABI version of linux-image."

Today, the available choices for the dependencies are:

  Package: foo-module-2.6-686
  Depends: foo-module-2.6.21-4-686, linux-image-2.6-686

or

  Package: foo-module-2.6-686
  Depends: foo-module-2.6.21-4-686, linux-image-2.6.21-4-686

Neither ensures that linux-image-2.6-686 and foo-module-2.6-686 are upgraded
together, which is what is being asked for.  This is a desirable goal,
because without this constraint, users who have both packages installed may
have linux-image-2.6-686 upgraded before the new version of
foo-module-2.6-686 is available, rendering their system unusable on reboot.

AFAICS, the best way to achieve this is to include the ABI information in
the version number of the linux-image metapackage.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #70 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Steve Langasek <vorlon@debian.org>, 428783@bugs.debian.org

Cc: Raphael Hertzog <hertzog@debian.org>

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 28 Jun 2007 18:39:05 +0200

On Wed, Jun 27, 2007 at 11:53:17AM -0700, Steve Langasek wrote:
> Neither ensures that linux-image-2.6-686 and foo-module-2.6-686 are upgraded
> together, which is what is being asked for.  This is a desirable goal,
> because without this constraint, users who have both packages installed may
> have linux-image-2.6-686 upgraded before the new version of
> foo-module-2.6-686 is available, rendering their system unusable on reboot.

Got it.

> AFAICS, the best way to achieve this is to include the ABI information in
> the version number of the linux-image metapackage.

Hmm. We need linux-modules metapackages than also. And it may be easier
to use virtual packages instead of versions. Something like:

| Package: linux-image-2.6-686
| Provides: linux-modules-2.6-686, linux-modules-latest-2.6.21-1-686
(normal)

| Package: linux-modules-2.6-xen-686
| Provides: linux-modules-latest-2.6.21-1-xen-686
(xen)

| Package: foo-modules-2.6-686
| Depends: linux-modules-latest-2.6.21-1-686

Otherwise broken down images like xen needs different handling from real
images. I don't want to do a real linux-modules for normal images.

Bastian 

-- 
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
		-- Kirk, "The Ultimate Computer", stardate 4731.3

Message #75 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Bastian Blank <waldi@debian.org>

Cc: Steve Langasek <vorlon@debian.org>, 428783@bugs.debian.org

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Thu, 28 Jun 2007 19:05:16 +0200

Hi,

On Thu, 28 Jun 2007, Bastian Blank wrote:
> > AFAICS, the best way to achieve this is to include the ABI information in
> > the version number of the linux-image metapackage.
> 
> Hmm. We need linux-modules metapackages than also. And it may be easier
> to use virtual packages instead of versions. Something like:
> 
> | Package: linux-image-2.6-686
> | Provides: linux-modules-2.6-686, linux-modules-latest-2.6.21-1-686
> (normal)
> 
> | Package: linux-modules-2.6-xen-686
> | Provides: linux-modules-latest-2.6.21-1-xen-686
> (xen)
> 
> | Package: foo-modules-2.6-686
> | Depends: linux-modules-latest-2.6.21-1-686
> 
> Otherwise broken down images like xen needs different handling from real
> images. I don't want to do a real linux-modules for normal images.

This looks like a good solution too. I'm not sure I like the name of the
provided package but that's nitpicking at this point. What about
linux-latest-abi-2.6.21-1-686?

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Message #82 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Steve Langasek <vorlon@debian.org>, 428783@bugs.debian.org

Cc: Raphael Hertzog <hertzog@debian.org>

Subject: Re: Bug#428783: linux-latest-2.6: Use new Breaks field to avoid installing new kernel image if old packaged modules are installed

Date: Fri, 29 Jun 2007 16:47:24 +0200

On Thu, Jun 28, 2007 at 06:39:05PM +0200, Bastian Blank wrote:
> Hmm. We need linux-modules metapackages than also. And it may be easier
> to use virtual packages instead of versions. Something like:

Commited. Both the linux-latest-2.6 and the linux-modules-* changes.
Hope I don't break it.

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
		-- Commander Kor, "Errand of Mercy", stardate 3201.7

Message #87 received at 428783-close@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: 428783-close@bugs.debian.org

Subject: Bug#428783: fixed in linux-latest-2.6 8

Date: Mon, 02 Jul 2007 12:32:03 +0000

Source: linux-latest-2.6
Source-Version: 8

We believe that the bug you reported is fixed in the latest version of
linux-latest-2.6, which is due to be installed in the Debian FTP archive:

linux-headers-2.6-powerpc-miboot_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-powerpc-miboot_2.6.21+8_powerpc.deb
linux-headers-2.6-powerpc-smp_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-powerpc-smp_2.6.21+8_powerpc.deb
linux-headers-2.6-powerpc64_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-powerpc64_2.6.21+8_powerpc.deb
linux-headers-2.6-powerpc_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-powerpc_2.6.21+8_powerpc.deb
linux-headers-2.6-prep_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-prep_2.6.21+8_powerpc.deb
linux-headers-2.6-vserver-powerpc64_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-vserver-powerpc64_2.6.21+8_powerpc.deb
linux-headers-2.6-vserver-powerpc_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-headers-2.6-vserver-powerpc_2.6.21+8_powerpc.deb
linux-image-2.6-powerpc-miboot_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-powerpc-miboot_2.6.21+8_powerpc.deb
linux-image-2.6-powerpc-smp_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-powerpc-smp_2.6.21+8_powerpc.deb
linux-image-2.6-powerpc64_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-powerpc64_2.6.21+8_powerpc.deb
linux-image-2.6-powerpc_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-powerpc_2.6.21+8_powerpc.deb
linux-image-2.6-prep_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-prep_2.6.21+8_powerpc.deb
linux-image-2.6-vserver-powerpc64_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-vserver-powerpc64_2.6.21+8_powerpc.deb
linux-image-2.6-vserver-powerpc_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-2.6-vserver-powerpc_2.6.21+8_powerpc.deb
linux-image-powerpc-miboot_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-powerpc-miboot_2.6.21+8_powerpc.deb
linux-image-powerpc-smp_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-powerpc-smp_2.6.21+8_powerpc.deb
linux-image-powerpc64_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-powerpc64_2.6.21+8_powerpc.deb
linux-image-powerpc_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-powerpc_2.6.21+8_powerpc.deb
linux-image-prep_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-prep_2.6.21+8_powerpc.deb
linux-image-vserver-powerpc64_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-vserver-powerpc64_2.6.21+8_powerpc.deb
linux-image-vserver-powerpc_2.6.21+8_powerpc.deb
  to pool/main/l/linux-latest-2.6/linux-image-vserver-powerpc_2.6.21+8_powerpc.deb
linux-latest-2.6_8.dsc
  to pool/main/l/linux-latest-2.6/linux-latest-2.6_8.dsc
linux-latest-2.6_8.tar.gz
  to pool/main/l/linux-latest-2.6/linux-latest-2.6_8.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 428783@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bastian Blank <waldi@debian.org> (supplier of updated linux-latest-2.6 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 02 Jul 2007 14:22:21 +0200
Source: linux-latest-2.6
Binary: linux-image-2.6-powerpc-miboot linux-headers-2.6-vserver-alpha linux-image-2.6-footbridge linux-image-2.6-parisc64 linux-image-2.6-486 linux-headers-2.6-atari linux-headers-2.6-vserver-686 linux-headers-2.6-s390 linux-image-qemu linux-image-itanium linux-image-2.6-s390 linux-headers-2.6-sparc64-smp linux-image-2.6-sb1a-bcm91480b linux-image-footbridge linux-headers-2.6-qemu linux-image-2.6-qemu linux-headers-2.6-vserver-sparc64 linux-image-2.6-r5k-cobalt linux-image-2.6-versatile linux-image-atari linux-image-alpha-legacy linux-image-r5k-ip32 linux-image-2.6-r4k-ip22 linux-headers-2.6-powerpc-miboot linux-image-vserver-alpha linux-image-s390 linux-headers-2.6-r5k-cobalt linux-headers-2.6-r5k-ip32 linux-image-versatile linux-image-2.6-itanium linux-image-parisc-smp linux-image-2.6-parisc-smp linux-image-2.6-iop32x linux-image-2.6-vserver-powerpc64 linux-image-2.6-vserver-sparc64 linux-image-amiga linux-image-2.6-k7 linux-headers-2.6-prep linux-headers-2.6-sb1-bcm91250a linux-image-2.6-powerpc linux-image-parisc64-smp linux-image-sparc64-smp linux-headers-2.6-parisc64-smp linux-image-2.6-parisc64-smp linux-image-powerpc-smp linux-image-sb1a-bcm91480b linux-image-2.6-sb1-bcm91250a linux-image-2.6-alpha-generic linux-headers-2.6-powerpc linux-headers-2.6-sparc64 linux-headers-2.6-iop32x linux-image-powerpc64 linux-headers-2.6-powerpc64 linux-image-vserver-powerpc linux-image-vserver-powerpc64 linux-image-prep linux-headers-2.6-mac linux-image-2.6-mckinley linux-headers-2.6-vserver-powerpc linux-image-r4k-ip22 linux-headers-2.6-alpha-generic linux-image-vserver-686 linux-headers-2.6-alpha-smp linux-image-2.6-vserver-amd64 linux-image-686-bigmem linux-image-2.6-atari linux-headers-2.6-vserver-k7 linux-image-2.6-amd64 linux-image-2.6-vserver-s390x linux-headers-2.6-sb1a-bcm91480b linux-image-parisc64 linux-image-iop32x linux-image-vserver-k7 linux-image-2.6-parisc linux-image-2.6-alpha-legacy linux-image-mckinley linux-image-2.6-4kc-malta linux-image-2.6-s390-tape linux-image-2.6-sparc64-smp linux-headers-2.6-parisc linux-headers-2.6-s390x linux-image-2.6-ixp4xx linux-image-sb1-bcm91250a linux-image-2.6-vserver-686 linux-headers-2.6-vserver-powerpc64 linux-image-2.6-vserver-powerpc linux-image-ixp4xx linux-image-2.6-vserver-alpha linux-image-2.6-mac linux-image-r5k-cobalt linux-image-2.6-s390x linux-image-alpha-smp linux-image-vserver-s390x linux-image-parisc linux-headers-2.6-footbridge linux-headers-2.6-4kc-malta linux-image-2.6-prep linux-image-2.6-sparc64 linux-image-s390-tape linux-headers-2.6-alpha-legacy linux-image-4kc-malta linux-headers-2.6-mckinley linux-headers-2.6-ixp4xx linux-headers-2.6-amd64 linux-image-powerpc-miboot linux-image-2.6-vserver-k7 linux-image-vserver-sparc64 linux-image-2.6-alpha-smp linux-image-686 linux-image-vserver-amd64 linux-headers-2.6-k7 linux-image-2.6-686-bigmem linux-image-k7 linux-headers-2.6-versatile linux-image-alpha-generic linux-image-2.6-powerpc-smp linux-image-s390x linux-image-486 linux-image-amd64 linux-headers-2.6-686 linux-image-2.6-amiga linux-headers-2.6-amiga linux-image-powerpc linux-headers-2.6-parisc64 linux-image-2.6-r5k-ip32 linux-headers-2.6-686-bigmem linux-image-2.6-powerpc64 linux-headers-2.6-parisc-smp linux-headers-2.6-486 linux-image-mac linux-headers-2.6-vserver-amd64 linux-headers-2.6-r4k-ip22 linux-image-sparc64 linux-headers-2.6-itanium linux-headers-2.6-powerpc-smp linux-headers-2.6-vserver-s390x linux-image-2.6-686
Architecture: source powerpc
Version: 8
Distribution: unstable
Urgency: low
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: Bastian Blank <waldi@debian.org>
Description: 
 linux-headers-2.6-powerpc - Header files for Linux 2.6 on uniprocessor 32-bit PowerPC
 linux-headers-2.6-powerpc-miboot - Header files for Linux 2.6 on 32-bit PowerPC for miboot floppy
 linux-headers-2.6-powerpc-smp - Header files for Linux 2.6 on multiprocessor 32-bit PowerPC
 linux-headers-2.6-powerpc64 - Header files for Linux 2.6 on 64-bit PowerPC
 linux-headers-2.6-prep - Header files for Linux 2.6 on PReP PowerPC
 linux-headers-2.6-vserver-powerpc - Header files for Linux 2.6 on uniprocessor 32-bit PowerPC
 linux-headers-2.6-vserver-powerpc64 - Header files for Linux 2.6 on 64-bit PowerPC
 linux-image-2.6-powerpc - Linux 2.6 image on uniprocessor 32-bit PowerPC
 linux-image-2.6-powerpc-miboot - Linux 2.6 image on 32-bit PowerPC for miboot floppy
 linux-image-2.6-powerpc-smp - Linux 2.6 image on multiprocessor 32-bit PowerPC
 linux-image-2.6-powerpc64 - Linux 2.6 image on 64-bit PowerPC
 linux-image-2.6-prep - Linux 2.6 image on PReP PowerPC
 linux-image-2.6-vserver-powerpc - Linux 2.6 image on uniprocessor 32-bit PowerPC
 linux-image-2.6-vserver-powerpc64 - Linux 2.6 image on 64-bit PowerPC
 linux-image-powerpc - Linux image on uniprocessor 32-bit PowerPC
 linux-image-powerpc-miboot - Linux image on 32-bit PowerPC for miboot floppy
 linux-image-powerpc-smp - Linux image on multiprocessor 32-bit PowerPC
 linux-image-powerpc64 - Linux image on 64-bit PowerPC
 linux-image-prep - Linux image on PReP PowerPC
 linux-image-vserver-powerpc - Linux image on uniprocessor 32-bit PowerPC
 linux-image-vserver-powerpc64 - Linux image on 64-bit PowerPC
Closes: 428783
Changes: 
 linux-latest-2.6 (8) unstable; urgency=low
 .
   * Update to 2.6.21-2.
   * Add modules meta packages.
   * Provide linux-latest-modules-*. (closes: #428783)
Files: 
 bac652ae4c36dbcbdaa2537556549e55 5107 admin optional linux-latest-2.6_8.dsc
 0e19c7545c853af3b4df5652e86d1152 12414 admin optional linux-latest-2.6_8.tar.gz
 992cdeb7d3f311dd4496fa12a946b5e4 2130 admin optional linux-image-powerpc_2.6.21+8_powerpc.deb
 4ce014d1a2bc8b93362ec38816be56cb 2152 admin optional linux-image-2.6-powerpc_2.6.21+8_powerpc.deb
 6b8471c2806b78b3fd3f99d5313a9a75 2162 devel optional linux-headers-2.6-powerpc_2.6.21+8_powerpc.deb
 6fb6e1ade814cabc2fc6ff7ce9b3082b 2132 admin optional linux-image-powerpc-smp_2.6.21+8_powerpc.deb
 399ea515caa2a2ce222c9ec6bf9e0263 2160 admin optional linux-image-2.6-powerpc-smp_2.6.21+8_powerpc.deb
 f55eee4368b29d19a0bd5f4ff25d720a 2168 devel optional linux-headers-2.6-powerpc-smp_2.6.21+8_powerpc.deb
 ac6f8fa94d10914c5159c811f54c13ed 2140 admin optional linux-image-powerpc-miboot_2.6.21+8_powerpc.deb
 93e2f5305f18a83898ac8e8f8afb2f2b 2166 admin optional linux-image-2.6-powerpc-miboot_2.6.21+8_powerpc.deb
 7ae08d8dc5db6cfa7ea43ca4bcff6d02 2174 devel optional linux-headers-2.6-powerpc-miboot_2.6.21+8_powerpc.deb
 c35e61de9fef4f53a0d03fb91d84db61 2118 admin optional linux-image-powerpc64_2.6.21+8_powerpc.deb
 f45310a8d3fe8d00f6e7c4b86c7251b9 2146 admin optional linux-image-2.6-powerpc64_2.6.21+8_powerpc.deb
 e77114ccb41d0ee34a26c3dd0e9d06d4 2152 devel optional linux-headers-2.6-powerpc64_2.6.21+8_powerpc.deb
 4a72cf09b3395ddea52172d7405940c9 2114 admin optional linux-image-prep_2.6.21+8_powerpc.deb
 6d0ccbfb3dd05a3b8d80a5b599043a72 2134 admin optional linux-image-2.6-prep_2.6.21+8_powerpc.deb
 3dd2651f037cd4671499574afdc921ad 2150 devel optional linux-headers-2.6-prep_2.6.21+8_powerpc.deb
 d8f3cc9ef0fc60ca5798af2bafd38da6 2140 admin optional linux-image-vserver-powerpc_2.6.21+8_powerpc.deb
 f5f5ac4e825550dba35ef77d0da8560b 2166 admin optional linux-image-2.6-vserver-powerpc_2.6.21+8_powerpc.deb
 6af5ada04946389b84bc89ee76114252 2172 devel optional linux-headers-2.6-vserver-powerpc_2.6.21+8_powerpc.deb
 bc272c7b870668035ab7b475c67658e2 2138 admin optional linux-image-vserver-powerpc64_2.6.21+8_powerpc.deb
 51049bf2ad207017a9754529bbe70ca1 2164 admin optional linux-image-2.6-vserver-powerpc64_2.6.21+8_powerpc.deb
 9607da3fd03a0849c4fdfe63b00a7a25 2178 devel optional linux-headers-2.6-vserver-powerpc64_2.6.21+8_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iEYEARECAAYFAkaI7okACgkQLkAIIn9ODhGoPQCgxSm/N1EOD1oI05+Rxzf6MDvC
vwsAoKc+ft5oO43HXa+YgYRa5NAk+YrZ
=lqDX
-----END PGP SIGNATURE-----

Message #92 received at 428783@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: 428783@bugs.debian.org

Subject: Re: Bug#428783 closed by Bastian Blank <waldi@debian.org> (Bug#428783: fixed in linux-latest-2.6 8)

Date: Mon, 2 Jul 2007 15:23:10 +0200

On Mon, 02 Jul 2007, Debian Bug Tracking System wrote:
>    * Update to 2.6.21-2.
>    * Add modules meta packages.
>    * Provide linux-latest-modules-*. (closes: #428783)

Now it would be good to communicate that new scheme to all maintainers of
modules packages.

For a start I tried to document it in
http://wiki.debian.org/DebianKernelABIChanges

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/

Send a report that this bug log contains spam.