Re: [PATCH] linux-custom: skip linux-libc-dev deployment on downgrade

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 23 Jan 2019 19:03:23 +0100
schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:

> Am Wed, 23 Jan 2019 18:43:08 +0100
> schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
> > On 23.01.19 18:30, Henning Schild wrote:  
> > > Am Wed, 23 Jan 2019 18:26:08 +0100
> > > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> > >     
> > >> On 23.01.19 18:23, [ext] Henning Schild wrote:    
> > >>> Ping
> > >>>        
> > >>
> > >> Looks good to me - what scenarios did you test?    
> > > 
> > > I know the breakages of buildchroot from layers, and the not
> > > deploying the kernel downgrade helped fix the issues.
> > > In this repo i honestly only tested the logic and whether the
> > > warning will pop up. Tested a qemuamd64 with the cip kernel inside
> > > Isar.   
> > 
> > OK, but we also have a "should upgrade" kernel recipe in Isar: 
> > linux-mainline_4.19.0.  
> 
> I just tested the "gt" operator of the comparator against the 4.9 that
> we get in debian 9. It worked there so there is no reason to think it
> will not work for 4.19.
> 
> > 
> > One question on second thought:
> >   
> > > +
> > > +# linux-libc-dev causes dependency problems if we downgrade
> > > +# remove it after the build so the downgraded version does not
> > > get deployed +LINUX_LIBC_DEV_V=`dpkg-query --show --showformat
> > > '${Version}' linux-libc-dev` +if dpkg --compare-versions
> > > $LINUX_LIBC_DEV_V gt $PV; then
> > > +	rm -f linux-libc-dev_${PV}*.deb
> > > +fi    
> > 
> > Isn't this assuming we have linux-libc-dev from Debian installed? Is
> > that always valid? Wouldn't it be better to query the Debian repo
> > specifically?  
> 
> Assuming you are installing only one kernel in your image, the command
> will operate on linux-libc-dev from all repos but ours ... debian.
> I guess if we are looking at images with multiple kernels, or
> incremental builds that downgrade against their own upgrade ... things
> could get tricky. Or actually not, in this case we want to get
> notified about the downgrade in our repo.
> 
> Say your debian official kernel is 4.9, your layer adds 4.14.42 and
> you go back to 4.14.40 in an incremental build step. The upgrade from
> 4.9 to 4.14.42 will be done as usual, and you should now receive the
> warning about a downgrade that will not be performed. ... Not
> tested ...

In fact that might not be true. reprepro will probably drop the 4.14.42
so it will not be seen at install time of 4.14.40. But still we will
always detect if we fall below the greatest version coming from a repo
we do not manage ... the debian default or your other mirror.

Henning

> So i am guessing the logic is correct. For the multiple kernel case
> (does that even exist?) one might have to ignore the warning or
> enforce an install order with artificial dependencies.
> 
> > Also: $(...) - `...` is old-style.  
> 
> Ok will fix.
> 
> Henning
> 
> > Jan
> >   
>