vyos-live-build.git/functions/packages.sh, branch rolling

packages.sh: check for /etc/debian_version existance rather than dpkg-query aviability

2021-01-13T12:39:07+00:00

s/Remove_package/Remove_packages/

2020-05-05T18:55:28+00:00

it removes one or more, so should be plural for clarity Gbp-Dch: Short

s/Install_package/Install_packages/

2020-05-05T18:55:28+00:00

it installs one or more, so should be plural for clarity Gbp-Dch: Short

packages: avoid unnecessary nesting

2020-05-05T18:55:28+00:00

Gbp-Dch: Ignore

make temporary state of installed tools recoverable

2020-05-05T18:43:15+00:00

some scripts temporarily install packages to accomplish some work before then removing them. the list of packages installed is kept in memory in a variable. a weakness of this design is that if a failure occurs or the user cancels, and then following this the user re-runs `lb build`, letting it try to pick up and recover from where it left off, that list of packages that had been installed is lost, resulting in those packages that were installed then being a permanent part of the chroot. here we fix this weakness by backing up the list to a file, which is always read from on removal. thus in a recovery situation, any packages still installed from a situation like that just described, will be removed upon the next use of `Remove_package()`. this is not perfect, since we are having to wait for opportunistic execution of the remove function. we need to find a suitable place for the `Cleanup_temp_packages()` function to be used. - doing so in `Init_config_data()` would not be suitable because we don't hold the lock when that's run, even if we ignored the hijacking of that function for taking such action... - doing it in `Exit()` doesn't seem a good fit either. - putting it explicitly in every build script just seems a little messy... perhaps a local exit trap like for removing the lock...? note that `binary_rootfs` skips running the remove function after installing tooling, since it just throws the wrapper chroot away, which then leaves the file around with stale data for the next remove instance to pick up, which then does not actually remove it because it's not installed. this is not ideal either... perhaps the optimisation should be removed from that script? Gbp-Dch: Short

Replace 'which' with 'command -v' to test for the existance of an executable

2020-05-01T09:59:11+00:00

This is considered to be more robust. Two instances remain: scripts/build/chroot_archives, line 257: if [ "${LB_APT}" = "aptitude" ] && [ ! $(Chroot chroot "which aptitude") ] The command is run inside a chroot where the environment might be special, and would need further testing. manpages/Makefile, line 42: @if [ ! -x "$$(which po4a 2>/dev/null)" ]; \ I am insufficiently familiar with makefile syntax to edit this.

packages: remove auto-installed on removal

2020-04-23T09:25:17+00:00

i've been noticing that in the binary_syslinux stage a wholebunch of packages get installed whilst installing isolinux, and then upon removing the installed packages at the end of the script, apt is listing a large number of those that were auto installed as no longer in use and can be removed via `apt autoremove`. this then persists through package installation and removal steps throughout remaining scripts. adding `--auto-remove` to `apt-get remove --purge` and similarly `--purge-unused` to `aptitude purge` instructs apt to get rid of the unused auto-installed packages at the same time as removing specific package that brought them in in the first place, and thus resolves the problem. Gbp-Dch: Short

use local scope for private function vars

2020-03-16T22:10:03+00:00

all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short

Revert "Test for executables: replace 'which' with more robust 'command -v'"

2020-03-12T12:32:26+00:00

This reverts commit 2d9ab1f7f82f9a98b97d1503c1e3f31c86061c15. Causes test failure due to bashism.

Test for executables: replace 'which' with more robust 'command -v'

2020-03-12T10:35:57+00:00

Instances of: if [ $(which ] have been replaced with: if command -v >/dev/null which is considered to be more robust in a range of environments. scripts/build/chroot_archives: line 259: if [ "${LB_APT}" = "aptitude" ] && [ ! $(Chroot chroot "which aptitude") ] has been left untouched because the chroot might require a more complex command which would need more testing. manpages/Makefile: line 42: @if [ ! -x "$$(which po4a 2>/dev/null)" ]; \ has been left untouched because I am not sufficiently familiar with makefiles.