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.

> 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.

> 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.