live-build/functions/packages.sh

173 lines
3.8 KiB
Bash
Raw Permalink Normal View History

2007-09-23 08:04:51 +00:00
#!/bin/sh
## live-build(7) - System Build Scripts
## Copyright (C) 2016-2020 The Debian Live team
## Copyright (C) 2006-2015 Daniel Baumann <mail@daniel-baumann.ch>
##
## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
## This is free software, and you are welcome to redistribute it
## under certain conditions; see COPYING for details.
2007-09-23 08:04:51 +00:00
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
# The file that records temporarily installed packages.
Installed_tmp_packages_file ()
{
echo "chroot.installed_tmp_pkgs"
}
# Note, writes to _LB_PACKAGES
2007-09-23 08:04:51 +00:00
Check_package ()
{
local CHROOT="${1}"
local FILE="${2}"
local PACKAGE="${3}"
2007-09-23 08:04:51 +00:00
Check_installed "${CHROOT}" "${FILE}" "${PACKAGE}"
2007-09-23 08:05:15 +00:00
if [ "${INSTALL_STATUS}" -ne 0 ]
then
if [ "${LB_BUILD_WITH_CHROOT}" != "false" ] && [ "${CHROOT}" = "chroot" ]
then
_LB_PACKAGES="${_LB_PACKAGES} ${PACKAGE}"
else
Echo_error "You need to install %s on your host system." "${PACKAGE}"
2007-09-23 08:05:17 +00:00
exit 1
fi
fi
2007-09-23 08:04:51 +00:00
}
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
# Note, reads from _LB_PACKAGES
Install_packages ()
2007-09-23 08:04:51 +00:00
{
if [ -z "${_LB_PACKAGES}" ] || [ "${LB_BUILD_WITH_CHROOT}" != "true" ]; then
return
2007-09-23 08:04:51 +00:00
fi
# Record in file to survive failure such that recovery can take place.
local LIST_FILE
LIST_FILE="$(Installed_tmp_packages_file)"
local PACKAGE
for PACKAGE in ${_LB_PACKAGES}; do
echo "${PACKAGE}" >> "${LIST_FILE}"
done
case "${LB_APT}" in
apt|apt-get)
Chroot chroot "apt-get install -o APT::Install-Recommends=false ${APT_OPTIONS} ${_LB_PACKAGES}"
;;
aptitude)
Chroot chroot "aptitude install --without-recommends ${APTITUDE_OPTIONS} ${_LB_PACKAGES}"
;;
esac
unset _LB_PACKAGES # Can clear this now
2007-09-23 08:04:51 +00:00
}
Remove_packages ()
2007-09-23 08:04:51 +00:00
{
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
if [ "${LB_BUILD_WITH_CHROOT}" != "true" ]; then
return
fi
local LIST_FILE
LIST_FILE="$(Installed_tmp_packages_file)"
# List is read from file to ensure packages from any past failure are
# included in the list on re-running scripts to recover.
local PACKAGES=""
if [ -e "${LIST_FILE}" ]; then
local PACKAGE
while read -r PACKAGE; do
PACKAGES="${PACKAGES} ${PACKAGE}"
done < "${LIST_FILE}"
fi
if [ -n "${PACKAGES}" ]; then
case "${LB_APT}" in
2007-09-23 08:04:51 +00:00
apt|apt-get)
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
Chroot chroot "apt-get remove --auto-remove --purge ${APT_OPTIONS} ${PACKAGES}"
2007-09-23 08:04:51 +00:00
;;
aptitude)
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
Chroot chroot "aptitude purge --purge-unused ${APTITUDE_OPTIONS} ${PACKAGES}"
2007-09-23 08:04:51 +00:00
;;
esac
fi
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
rm -f "${LIST_FILE}"
}
#FIXME: make use of this. see commit log that added this for details.
# Perform temp package removal for recovery if necessary
Cleanup_temp_packages ()
{
if [ -e "$(Installed_tmp_packages_file)" ]; then
Remove_packages
make temporary state of installed tools recoverable 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
2020-05-05 00:56:36 +00:00
fi
2007-09-23 08:04:51 +00:00
}
2007-09-23 08:05:17 +00:00
# Check_installed
# uses as return value global var INSTALL_STATUS
# INSTALL_STATUS : 0 if package is installed
# 1 if package isn't installed and we're in an apt managed system
# 2 if package isn't installed and we aren't in an apt managed system
Check_installed ()
{
local CHROOT="${1}"
local FILE="${2}"
local PACKAGE="${3}"
2007-09-23 08:05:17 +00:00
if [ "${LB_BUILD_WITH_CHROOT}" = "true" ] && [ "${CHROOT}" = "chroot" ]
then
if Chroot chroot "dpkg-query -s ${PACKAGE}" 2> /dev/null | grep -qs "Status: install"
then
INSTALL_STATUS=0
else
INSTALL_STATUS=1
fi
else
if [ -e /etc/debian_version ]
then
if dpkg-query -s "${PACKAGE}" 2> /dev/null | grep -qs "Status: install"
2007-09-23 08:05:17 +00:00
then
INSTALL_STATUS=0
else
INSTALL_STATUS=1
fi
else
if [ ! -e "${FILE}" ]
2007-09-23 08:05:17 +00:00
then
INSTALL_STATUS=2
2007-09-23 08:05:17 +00:00
else
INSTALL_STATUS=0
2007-09-23 08:05:17 +00:00
fi
fi
fi
2007-09-23 08:05:17 +00:00
}
# $1 = Packagename
# Echoes:
# 1 if the package is available
# 0 otherwise
Check_package_available ()
{
local _PACKAGE="${1}"
if [ "${LB_BUILD_WITH_CHROOT}" = "true" ]
then
if [ $(Chroot chroot apt-cache show "^${_PACKAGE}$" 2> /dev/null | grep "^Package:" | wc -l) -eq 1 ]
then
echo 1
return
fi
else
if [ $(apt-cache show "^${_PACKAGE}$" 2> /dev/null | grep "^Package:" | wc -l) -eq 1 ]
then
echo 1
return
fi
fi
echo 0
}