Re: apt-mark hold package within postinst

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

Am Mon, 26 Sep 2022 09:53:26 +0200
schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>:

> Il Lun 26 Set 2022, 09:09 Henning Schild <henning.schild@siemens.com>
> ha scritto:
> 
> > Am Sat, 24 Sep 2022 22:53:22 +0200
> > schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>:
> >  
> > > Il Ven 23 Set 2022, 12:56 Henning Schild
> > > <henning.schild@siemens.com> ha scritto:
> > >  
> > > > Am Fri, 23 Sep 2022 11:58:53 +0200
> > > > schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>:
> > > >  
> > > > > Il Ven 23 Set 2022, 11:22 Roberto A. Foglietta
> > > > > <roberto.foglietta@gmail.com> ha scritto:
> > > > >  
> > > > > > Hi all,
> > > > > >
> > > > > >  .deb repackaged should not upgrade with any external
> > > > > > source so they should marked on hold. Easy but not possible
> > > > > > to do within postinst obviously. Not in a straight way, at
> > > > > > least. Am I wrong? 
> > > >
> > > > I you rebuild you should add some suffix to PV
> > > >
> > > > CHANGELOG_V ?= "${PV}+roberto"
> > > >
> > > > During installation of isar itself your rebuilt package will win
> > > > anyways. Make sure to add it to IMAGE_INSTALL instead of
> > > > PREINSTALL, or make sure to have a bitbake DEPENDS if it comes
> > > > in via a debian dep chain.
> > > >
> > > > But during lifetime any apt-get upgrade could replace yours when
> > > > debian brings an update. To deal with that it is best to deploy
> > > > a preferences file with some dpkg-raw configuration package.
> > > >
> > > > roberto-pin_0.1.bb:
> > > > inherit dpkg-raw
> > > > do_install() {
> > > >   echo -e "Package: *\nPin: version *+roberto*\nPin-Priority:
> > > > 1000"  
> > > > > ${D}/etc/apt/preferences.d/${PN}  
> > > > }
> > > >
> > > > With this all packages that have the roberto suffix will become
> > > > non-replaceable ... unless someone uses that same suffix.
> > > >
> > > > Generally you want to try and mainline all your changes to avoid
> > > > local rebuilds.
> > > >
> > > > Another trick would be an empty package that conflicts with
> > > > anything greater than "${PV}+roberto", that should also prevent
> > > > updates. Not sure which way is better.
> > > >
> > > > We mostly build images that are replaces as a whole and will
> > > > not get much "apt-get" during their life. Note that kernel
> > > > updates with apt-get will not easily work in an isar built
> > > > image. It will depend on your bootloader whether it might work,
> > > > and you might have to add scripts that update bootloader
> > > > configs after kernel install. 
> > >
> > > Dear Henning,
> > >
> > >  first of all, thank you for your explanation. I think about it
> > > and I arrived to the conclusion that your solution is good but top
> > > definitive for my need/goals.
> > >
> > > The problem is 1. that even wintout any update available the
> > > original packages are seen as updates and  
> >
> > That should not happen, if it really does we need to fix that. When
> > the rootfs gets its packages installed all the ones build with isar
> > should have higher prio even if one is a rebuild that did not
> > increase the PV.
> >
> > Maybe you can send an example where that does not work as expected.
> >  
> 
> Ok, I will investigate it deeply.
> 
> 
> > 2. I wish to avoid that the user  
> > > upgrade the repackaged packages installing the dependencies I
> > > removed.
> > >
> > > However, I am not interested in make their upgrade difficult.
> > > Probably, I will keep only hold the packages at the installation
> > > but even remove the holding as configuration.  
> >
> > If you system is really closed/embedded but somehow open for
> > someone to install updates and additional stuff ... i would again
> > like to really stress that rdep removal is a really bad idea. You
> > will not know what people do and you seriously break their
> > assumptions if they think they deal with debian/ubuntu.
> > Do only modify that debian for a really good reason! You could see
> > with the removed man-pages and than "jre" can not be installed
> > anymore. 
> 
> It is an evaluation system aimed to be tried by human users.
> 
> 
> > Just a way to avoid that kids break up the system just with a basic
> >  
> > > admin operation without further complications.  
> >
> > That sounds like security might be your reasoning to remove some
> > packages. Installing less naturally decreases the attack surface,
> > but the removal also can have a negative impact on the availability
> > ... also security.
> > Software stacks are simply large and keep growing. You might want to
> > consider apparmor or selinux instead of ripping out bits without a
> > concrete problem. Debian will handle CVEs just fine for you, if you
> > mess with it you rather risk that their updates will not fit on your
> > modified system.
> >  
> 
> As every evaluation system, it has no security nor any quality/grade
> granted.
> 
> However, I do not want it breaks apart in a minute by any
> reasonable/expected user interaction.
> 
> It should reasonably work as proof-of-concept / commercial-demo, ONLY.

In that case skip _all_ customization. Let the docs installed, all
runtime deps etc. Just install a debian, your applications and deploy
your preconfiguration ... done.

That is also the advice i would have for any product, but there one
sometimes sees very strange requirements/constraints which force one to
touch what one should not. ... that debian base ...

Henning

> Others people more experienced of me will be in charge to provide the
> custom system for the production with an industrial grade and
> everything else is needed for that market positioning.
> 
> Thanks, R-
> 
> >