[Solved] PKGBUILD user error prevention vs intrusive sanity checks.

Question

I read over the AUR packaging standards and am pretty familiar with creating PKGBUILDs but I'm uncertain on how to proceed when I need to check a system file so the user doesn't accidently install a package that may or may not mess up their system. I don't know how I feel about checking a user's system files from within a PKGBUILD. To be more specific; I'm maintaining "util-linux-aes" which is the util-linux package with loop-AES support (via patch). As brought to my attention by 'gemon' on the AUR page: http://aur.archlinux.org/packages.php?ID=47060  I should probably check if user has a kernel with loop-AES (loop.[k]o) patched as it may cause harm to their system if they use util-linux-aes and don't have a patched kernel. I'm somewhat torn about how to address the situation. Should a simple echo message suffice, giving warning about installing or should I insert code (as shown below) to check for proper kernel config options?
I thought about adding a kernel config check in a util-linux-aes.install file but if it returns or exits with 1 the package still installs. So I had to migrate the check to the PKGBUILD itself (which makes more sense I guess) and I'm not sure if this is considered an "intrusion" and/or unclean method of dealing with this. To make things more clear, here's my proposed PKGBUILD (current PKGBUILD doesn't have the config check):
# Maintainer: milomouse <vincent[at]fea.st>
# Contributor: judd <jvinet[at]zeroflux.org>
_basename=util-linux
pkgname=${_basename}-aes
pkgver=2.19
pkgrel=5
pkgdesc="Miscellaneous system utilities for Linux, with loop-AES support"
url="http://userweb.kernel.org/~kzak/util-linux-ng/"
license=('GPL2')
arch=('i686' 'x86_64')
groups=('base')
depends=('bash' 'ncurses>=5.7' 'zlib' 'filesystem')
optdepends=('perl: for chkdupexe support')
provides=('linux32' "util-linux=${pkgver}" "util-linux-ng=${pkgver}")
conflicts=('linux32' 'util-linux' 'util-linux-ng' 'e2fsprogs<1.41.8-2')
replaces=('linux32' 'util-linux' 'util-linux-ng')
options=('!libtool')
_loopaesdate=20110226
_loopaesvers=v3.6b
_loopaesdiff=${_basename}-${pkgver}.diff
source=(http://www.kernel.org/pub/linux/utils/${_basename}/v${pkgver}/${_basename}-${pkgver}.tar.bz2
http://downloads.sourceforge.net/project/loop-aes/loop-aes/${_loopaesvers}/loop-AES-${_loopaesvers}.tar.bz2)
build() {
cd "${srcdir}/${_basename}-${pkgver}"
# check for compatability first
warning "You must also have a loop-AES patched kernel (loop.ko) for this to work."
warning "You may end up damaging your system otherwise. Checking now..."
if [[ -f /proc/config.gz ]]; then
if [[ $(zgrep CONFIG_BLK_DEV_LOOP= /proc/config.gz) == CONFIG_BLK_DEV_LOOP=[ym] && \
$(zgrep CONFIG_BLK_DEV_LOOP_AES= /proc/config.gz) == CONFIG_BLK_DEV_LOOP_AES=y ]]; then
msg "Everything looks OK."
else
error "CONFIG_BLK_DEV_LOOP / CONFIG_BLK_DEV_LOOP_AES are not correct, aborting!"
return 1
fi
elif [[ -f /usr/src/linux-$(uname -r)/.config ]]; then
if [[ $(zgrep CONFIG_BLK_DEV_LOOP= /usr/src/linux-$(uname -r)/.config) == CONFIG_BLK_DEV_LOOP=[ym] && \
$(zgrep CONFIG_BLK_DEV_LOOP_AES= /usr/src/linux-$(uname -r)/.config) == CONFIG_BLK_DEV_LOOP_AES=y ]]; then
msg "Everything looks OK."
else
error "CONFIG_BLK_DEV_LOOP / CONFIG_BLK_DEV_LOOP_AES are not correct, aborting!"
return 1
fi
else
error "Cannot find a kernel config to check options, aborting build!"
error "If you're POSITIVE you have a patched kernel, edit PKGBUILD to remove this."
return 1
fi
# if all went well; provide loop-aes support
patch -Np1 -i "${srcdir}/loop-AES-${_loopaesvers}/${_loopaesdiff}"
# hardware clock
sed -e 's%etc/adjtime%var/lib/hwclock/adjtime%' -i hwclock/hwclock.c
autoreconf
automake
./configure --enable-arch --enable-write --enable-raw --disable-wall --enable-partx
make
package() {
cd "${srcdir}/${_basename}-${pkgver}"
mkdir -p "${pkgdir}/var/lib/hwclock"
make DESTDIR="${pkgdir}" install
md5sums=(
'590ca71aad0b254e2631d84401f28255' # util-linux-2.19.tar.bz2
'247e5a909877577bdcd246f8caada689') # loop-AES-v3.6b.tar.bz2
sha384sums=(
'05e8e3a2685ff47c57d56bf9d5bfc9cbe5c1fa85200f403c5ccc08676b9b713fc935b3b040d5d5dcd2c5aa14b631f1bd' # util-linux-2.19.tar.bz2
'48ee55e996464f613d68e04bc661997a846989fef4d8a21fb0647c126c64e5ecdb218a37c75f6d3baccfebb2d89503ea') # loop-AES-v3.6b.tar.bz2
Is it too much [attempting to help the user] by doing this sort of check, is it considered bad practice?
Even if it's ok, I don't know if I'm going about checking this correctly, although in my mind it makes sense. Checking against the kernel config, I mean.
Advice on any of these aspects is appreciated, as I'd hate to think I'd unwittingly let a user harm their computer somehow by not checking or at least warning. Again, my main concern is if this is considered bad practice and if it is what are my alternatives. (if this has been discussed before, I'm sorry, just point me in the right direction, thanks).
Thanks for reading.
Last edited by milomouse (2011-03-04 15:51:50)

Answer 1

milomouse wrote:
@ngoonee:
My first instincts told me as such (also noted on AUR page comments), that a user should well know what this package is and what it does and need not be checked against their system, and those without the knowledge shouldn't be messing with it in the first place. But with another user of the package bringing the attention that some poor user might install this without full knowledge of it's implementation and/or thinking this package by itself may provide loop-AES (unknowing of kernel patch) they might fall prey to unbeknownst side-effects.
I guess a warning message will suffice for sanity's sake [under pre_install(), I guess], as I don't think I should create depends on an AUR kernel with current loop-AES support that I don't maintain myself (otherwise I'd have to follow it's inclusion).
Thanks for the support, though, albeit a bit rough. But for future reference; is checking a user's system files considered OK or should the same rules as this package apply (user knowledge)? I can't imagine every package installing OK without at least one of them checking against a user's current setup.
In general I don't think checking the current system is 'okay'. PKGBUILDs are meant to create packages. There's no reason these need to be created on the same system as they will be installed on (perhaps a chroot would be used just for building, or a buildserver). Or maybe someone may have multiple machines which share packages or the cache.
A depends would be the best option in this case, followed by the warning (the former does not mean the latter is not needed). Your check would fail in the cases I outline in the previous paragraph.