2007-09-23 08:04:51 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
2010-09-02 11:12:37 +00:00
|
|
|
## live-build(7) - System Build Scripts
|
2020-03-11 09:07:21 -01:00
|
|
|
## Copyright (C) 2016-2020 The Debian Live team
|
2015-01-04 18:05:39 -01:00
|
|
|
## Copyright (C) 2006-2015 Daniel Baumann <mail@daniel-baumann.ch>
|
2010-09-02 11:12:37 +00:00
|
|
|
##
|
2012-07-29 23:59:00 +00:00
|
|
|
## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
|
2010-09-02 11:12:37 +00:00
|
|
|
## 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 ()
|
|
|
|
{
|
2020-02-20 05:58:11 -01:00
|
|
|
local CHROOT="${1}"
|
|
|
|
local FILE="${2}"
|
|
|
|
local PACKAGE="${3}"
|
2007-09-23 08:04:51 +00:00
|
|
|
|
2015-01-04 16:08:09 -01:00
|
|
|
Check_installed "${CHROOT}" "${FILE}" "${PACKAGE}"
|
2007-09-23 08:05:15 +00:00
|
|
|
|
2017-08-28 13:14:34 +00:00
|
|
|
if [ "${INSTALL_STATUS}" -ne 0 ]
|
|
|
|
then
|
2018-04-04 19:26:39 +00:00
|
|
|
if [ "${LB_BUILD_WITH_CHROOT}" != "false" ] && [ "${CHROOT}" = "chroot" ]
|
2017-08-28 13:14:34 +00:00
|
|
|
then
|
2010-09-07 13:11:20 +00:00
|
|
|
_LB_PACKAGES="${_LB_PACKAGES} ${PACKAGE}"
|
2017-08-28 13:14:34 +00:00
|
|
|
else
|
2008-08-11 20:28:54 +00:00
|
|
|
Echo_error "You need to install %s on your host system." "${PACKAGE}"
|
2007-09-23 08:05:17 +00:00
|
|
|
exit 1
|
2017-08-28 13:14:34 +00:00
|
|
|
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
|
2020-05-05 15:42:44 +00:00
|
|
|
Install_packages ()
|
2007-09-23 08:04:51 +00:00
|
|
|
{
|
2020-05-05 18:29:36 +00:00
|
|
|
if [ -z "${_LB_PACKAGES}" ] || [ "${LB_BUILD_WITH_CHROOT}" != "true" ]; then
|
|
|
|
return
|
2007-09-23 08:04:51 +00:00
|
|
|
fi
|
2020-05-05 18:29:36 +00:00
|
|
|
|
|
|
|
# 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
|
|
|
}
|
|
|
|
|
2020-05-05 15:45:57 +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
|
2010-09-07 13:11:20 +00:00
|
|
|
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
|
2020-05-05 15:45:57 +00:00
|
|
|
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 ()
|
|
|
|
{
|
2020-02-20 05:58:11 -01:00
|
|
|
local CHROOT="${1}"
|
|
|
|
local FILE="${2}"
|
|
|
|
local PACKAGE="${3}"
|
2007-09-23 08:05:17 +00:00
|
|
|
|
2015-01-04 16:08:09 -01: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
|
2021-01-13 11:18:40 -01:00
|
|
|
if [ -e /etc/debian_version ]
|
2015-01-04 16:08:09 -01:00
|
|
|
then
|
2016-11-28 20:50:42 -01:00
|
|
|
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
|
2015-01-04 16:08:09 -01:00
|
|
|
else
|
|
|
|
if [ ! -e "${FILE}" ]
|
2007-09-23 08:05:17 +00:00
|
|
|
then
|
2015-01-04 16:08:09 -01:00
|
|
|
INSTALL_STATUS=2
|
2007-09-23 08:05:17 +00:00
|
|
|
else
|
2015-01-04 16:08:09 -01:00
|
|
|
INSTALL_STATUS=0
|
2007-09-23 08:05:17 +00:00
|
|
|
fi
|
2015-01-04 16:08:09 -01:00
|
|
|
fi
|
|
|
|
fi
|
2007-09-23 08:05:17 +00:00
|
|
|
}
|
|
|
|
|
2024-06-20 20:36:30 +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
|
|
|
|
}
|
|
|
|
|