Re: apt-mark hold package within postinst

["Roberto A. Foglietta" <roberto.foglietta@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4901 bytes --]

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.

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-

>

[-- Attachment #2: Type: text/html, Size: 7319 bytes --]