Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62793 > unrolled thread

Bug#916927: aptitude: should consistently choose between signed and unsigned kernels

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#916927: aptitude: should consistently choose between signed and unsigned kernels Ansgar Burchardt <ansgar@debian.org> - 2018-12-20 17:00 +0100
    Processed: Re: aptitude: should consistently choose between  signed and unsigned kernels "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-12-20 17:00 +0100
    Bug#916927: aptitude: should consistently choose between signed and unsigned kernels Ben Hutchings <ben@decadent.org.uk> - 2018-12-20 19:10 +0100

#62793 — Bug#916927: aptitude: should consistently choose between signed and unsigned kernels

Control: reassign -1 src:linux 4.19.9-1

On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote:
> After an upgrade of linux-image-amd64, which now depends on
> linux-image-4.19.0-1-amd64, on one machine I got:
> 
>   linux-image-4.19.0-1-amd64 4.19.9-1
> 
> but on another machine I got:
> 
>   linux-image-4.19.0-1-amd64-unsigned 4.19.9-1

The issue is that linux-image-4.19.0-1-amd64-unsigned has
  Provides: linux-image-4.19.0-1-amd64

So if linux-image-amd64 starts depending on linux-image-4.19.0-1-amd64
before the signed version is present, apt will install the unsigned
version.  This doesn't look like a bug in apt to me.

The easiest way to avoid this would be to drop the Provides from the
unsigned image.  Is there any downside for doing so?

Ansgar

[toc] | [next] | [standalone]

#62794 — Processed: Re: aptitude: should consistently choose between signed and unsigned kernels

Processing control commands:

> reassign -1 src:linux 4.19.9-1
Bug #916927 [aptitude] aptitude: should consistently choose between signed and unsigned kernels
Bug reassigned from package 'aptitude' to 'src:linux'.
No longer marked as found in versions aptitude/0.8.11-6.
Ignoring request to alter fixed versions of bug #916927 to the same values previously set
Bug #916927 [src:linux] aptitude: should consistently choose between signed and unsigned kernels
Marked as found in versions linux/4.19.9-1.

-- 
916927: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916927
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#62797

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2018-12-20 at 16:51 +0100, Ansgar Burchardt wrote:
> Control: reassign -1 src:linux 4.19.9-1
> 
> On Thu, 20 Dec 2018 16:26:55 +0100 Vincent Lefevre wrote:
> > After an upgrade of linux-image-amd64, which now depends on
> > linux-image-4.19.0-1-amd64, on one machine I got:
> > 
> >   linux-image-4.19.0-1-amd64 4.19.9-1
> > 
> > but on another machine I got:
> > 
> >   linux-image-4.19.0-1-amd64-unsigned 4.19.9-1
> 
> The issue is that linux-image-4.19.0-1-amd64-unsigned has
>   Provides: linux-image-4.19.0-1-amd64
> 
> So if linux-image-amd64 starts depending on linux-image-4.19.0-1-amd64
> before the signed version is present, apt will install the unsigned
> version.  This doesn't look like a bug in apt to me.
> 
> The easiest way to avoid this would be to drop the Provides from the
> unsigned image.  Is there any downside for doing so?

I was under the impression that packages built by module-assistant
generally depended on the corresponding kernel package.  Either this
changed at some point or I misremembered.

Since the signing service seems to be reliable I don't see any good
reason to actually use the unsigned packages, so I think the Provides
could safely be removed.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web