Opkg install also upgrades packages... safe when restoring?

Installing and Using OpenWrt
1

Hi all,
when restoring packages (obtained by opkg list-installed) from an old installation to a fresh one today (via opkg install <those_listed_packages>), I noticed that opkg is performing the upgrade of the specified packages in case they are already installed and upgradable.
(I noticed now for the first time as I never used packages backup/restore in the past with just a few extra packages).

Since I've always known that bulk upgrades are discouraged, but this is in practice exactly what is happening when we grab the full list of installed packages from and old installation to the new one and feed opkg install with it, isn't this (undocumented) opkg behaviour a bit dangerous? Should there be an opt-in/out option for the install command to also perform upgrades of existing packages, or at least have it documented?
I know one can also keep track of user-installed packages only and just restore those, or there is opkg extras I read, but this is also about the opkg behaviour afterall...

Just some thoughts... thanks.

2

"Opkg install also upgrades packages"

Yes, it does...if the package is already installed.

List of "upgradeable" packages on my device after running opkg list-upgradable -

root@OpenWrt:~# opkg list-upgradable
iwinfo - 2021-04-30-c45f0b58-2.1 - 2022-04-26-dc6847eb-1
nano - 6.2-2 - 6.3-1
libiwinfo-lua - 2021-04-30-c45f0b58-2.1 - 2022-04-26-dc6847eb-1
luci-mod-system - git-22.019.40321-7a37d02 - git-22.130.00635-21f99bd
libwolfssl5.2.0.99a5b54a - 5.2.0-stable-1 - 5.2.0-stable-2
firewall - 2021-03-23-61db17ed-1 - 2021-03-23-61db17ed-1.1
libiwinfo-data - 2021-04-30-c45f0b58-2.1 - 2022-04-26-dc6847eb-1
luci-base - git-22.083.69138-0a0ce2a - git-22.119.37126-a993714
libiwinfo20210430 - 2021-04-30-c45f0b58-2.1 - 2022-04-26-dc6847eb-1
htop - 3.1.2-1 - 3.2.0-1

After doing an opkg update, I decided to "upgrade" htop, by installing it over the top of the existing package.

It told me that it was upgrading the package to the new version number -

root@OpenWrt:~# opkg install htop
Upgrading htop on root from 3.1.2-1 to 3.2.0-1...
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/mips_24kc/packages/htop_3.2.0-1_mips_24kc.ipk
Configuring htop.

Confirmed with opkg list-installed -

root@OpenWrt:~# opkg list-installed | grep htop
htop - 3.2.0-1

Probably not a big a deal with custom packages, but definitely a big deal with lib packages (also in my list of "upgradables").

Most people get in trouble by blindly upgrading "everything".

I maintain a list of packages using opkg list-installed, and save the results to a text file with a unique file name, so I "version" my packages list.

I can then use a file diff program to see what's changed.

If I added a new package, I can simply add that package to a script I use to re-install custom packages.

OpenWrt will take care of the all the "base" packages needed when I upgrade the firmware to the next version, recover an install using TFTP or serial, or re-install the current version firmware.

1 Like
3

Yeah... my point is also that this is undocumented to begin with...

Eh... unfortunately this is what happens when using the full list of installed packages (including base packages) with opkg install... so my other point was that we wouldn't need to keep track of user-installed packages if opkg install just performed installations instead of upgrades.

This approach can be useful indeed... just diff opkg list-installed on the new one against the old one, and feed opkg install with it. Still not 100% clean I guess because of possible discontinued/changed packages maybe (like the full list solution too)...

Sure taking the effort of keeping a separate list/script of custom packages (not even their dependencies) is the best approach I guess... it's just not very practical and one can forget to update it everytime (since one may add new packages very infrequently and completely forget to update that list) compared to grabbing the list of installed packages in one command when needed...