apt-mark hold package within postinst

apt-mark hold package within postinst

[Roberto A. Foglietta]

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

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?

 Thanks, R-

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

Re: apt-mark hold package within postinst

[Roberto A. Foglietta]

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

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

This seems quite sane but it keeps the package in hold even if the users
lately decide to upgrade it (possibly with a fixed version).

echo 'APT::Update::Post-Invoke { "apt-mark hold pippo || true"; };' >>
/etc/apt/apt.conf.d/99isar-repackage-hold

My first try was to fork a process in post that waits the installation ends
and then marks the package in hold.

Opinions about?

Best regards, R.

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

Re: apt-mark hold package within postinst

[Henning Schild]

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.

Henning

> This seems quite sane but it keeps the package in hold even if the
> users lately decide to upgrade it (possibly with a fixed version).
> 
> echo 'APT::Update::Post-Invoke { "apt-mark hold pippo || true"; };' >>
> /etc/apt/apt.conf.d/99isar-repackage-hold
> 
> My first try was to fork a process in post that waits the
> installation ends and then marks the package in hold.
> 
> Opinions about?
> 
> Best regards, R.
> 

Re: apt-mark hold package within postinst

[Roberto A. Foglietta]

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

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

Just a way to avoid that kids break up the system just with a basic admin
operation without further complications.

Best regards, R-

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

Re: apt-mark hold package within postinst

[Henning Schild]

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.

Henning 
 
> Best regards, R-

Re: apt-mark hold package within postinst

[Roberto A. Foglietta]

[-- 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 --]

Re: apt-mark hold package within postinst

[Henning Schild]

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