apt-get upgrade package without backup

[gibi]

Hi all,

I maintain a debian package which contains several files for my embedded board

Code: Select all

>dpkg --contents myBootloader_1.0-3_armhf.deb
drwxr-xr-x root/root         0 2017-03-14 13:54 ./
drwxr-xr-x root/root         0 2017-03-14 13:53 ./boot/
-rw-r--r-- root/root     10284 2017-03-14 13:53 ./boot/devicetree.dtb
-rw-r--r-- root/root       230 2017-03-14 13:53 ./boot/uEnv.txt
...

Later I updated the devicetree.dtb. and changed the version of the package from 1.0-2 to 1.0-3. Because the boot partition is formatted as vfat, I got an error when I ugraded the package by apt-get.

Code: Select all

dpkg: error processing archive /var/cache/apt/archives/myBootloader_1.0-3_armhf.deb (--unpack):
 unable to make backup link of `./boot/devicetree.dtb' before installing new version: Operation not permitted
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/myBootloader_1.0-3_armhf.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

The problem is that dpkg tries to create a link on the boot partition to backup the old files. But since the boot partition is vfat no links can be created.
So I had the following ideas:

• in debian/control add a conflict to the own package so apt-get removes first the old version (does not work)
• install the files in another temporary place of the ext4 partition and copy the files from /boot in the postinst script (is not really a clean and solution)

Do you have any other ideas to handle this problem? Or is there an official way to do it? To upgrade the package without removing the old one manually before?

[bigrigdriver]

Have you looked at the possibility of using dpkg-divert to handle that?

[gibi]

Thanks for the reply.

I haven't but dpkg-divert is to prevent another specific package to update a file, in my example the devicetree.dtb
Because I do not need this prevention I also just can move the devicetree in the preinst script and remove/copy it back in the postinst depending on the success of the installation.

Anyhow it looks like there is no way to get around the pre- and postinst scripts