hello,
seems like there is some weirdness happening with the way
chroot_apt/preferences is handled. I'm using yesterday's live-helper
snapshot package built for Lenny.
I want a custom pinning configuration to be used both during the image
build and inside the resulting live system, so I put the same custom
preferences file is chroot_apt/preferences and in
chroot_local-includes/etc/apt/preferences.
Here's what happens, in my understanding after some debug time, when
I run lh_build.
When 'lh_chroot_apt install' is called the first time (i.e.
by lh_chroot), chroot/etc/apt/preferences does not exist yet (as the
local-includes have not been copied yet), so the only thing happening
is 'cp config/chroot_apt/preferences chroot/etc/apt/preferences',
which is the desired behavior. Great.
lh_chroot then does the rest of its job and eventually runs
'lh_chroot_apt remove'. The corresponding piece of code that is run is
then:
# Deconfiguring apt preferences
if [ -f chroot/etc/apt/preferences.orig ]
then
mv chroot/etc/apt/preferences.orig
chroot/etc/apt/preferences
else
rm -f chroot/etc/apt/preferences
fi
No .orig file exists at this point, so the custom preferences file is
deleted from the chroot. You'll note that apt.conf is handled, a few
lines above, in a slightly different way... which actually works for
me. This piece of code was (re)written like this in commit
3aa34e3461baa90ff4af76b1af36e8afda16d65e, in order to "Fix a bug where
a /etc/apt/preferences supplied in chroot_local-includes was always
being deleted when used in conjunction with
config/chroot_apt/preferences". If I understand clearly what's going
on, this patch actually does not fix this issue: it would if
lh_chroot_local-includes was called before 'lh_chroot_apt install',
which is not the case.
lh_binary then itself runs 'lh_chroot_apt install-binary' and
'lh_chroot_apt remove', which once again copies the custom
chroot_apt/preferences file in, then deletes it.
Later in the build process, 'apt-get --yes upgrade' is run (apparently
by lh_chroot_sources, itself run by lh_source that does *not* run
lh_chroot_apt beforehand, which might actually be the root cause of
the problem)... on a system without any pinning configuration, which
upgrades - in my case - to squeeze packages initially installed from
lenny-backports.
I thus see two problems, although I may have missed something more or
less obvious:
1. lh_chroot_sources runs apt-get upgrade on a system without having
configured APT beforehand, which leads to the above described
undesired behavior.
2. a custom apt/preferences file has no chance to end in the generated
image
I guess #1 could be solved by running lh_chroot_apt like
lh_chroot does.
I guess #2 could be solved by handling it just like apt.conf in
'lh_chroot_apt remove'; the bug that was supposed to be fixed in
commit 3aa34e3461baa90ff4af76b1af36e8afda16d65e would still be
present, though. But: do we want /etc/apt/{apt.conf,preferences}
supplied in chroot_local-includes to take preference over the ones in
chroot_apt? It seems to me it would be harder to implement, but would
allow to build a live system with a different pinning configuration
than the one used for building... which I fail to see as a really
important feature. I thus propose the following:
- document that custom {apt.conf,preferences} files must be put in
chroot_apt, will be used during the build *and* be included in the
resulting images
- fix the implementation so that this is actually the case
This solution, though a bit limiting, would at least bring us an
understandable, consistent behavior wrt. these files.
I'm of course volunteering to implement my proposal.
By the way, 'Echo_message "Configuring file /etc/apt/apt.conf"' in
lh_chroot_apt is not up-to-date anymore, as this helper does far more
nowadays than configuring apt.conf.
[1]
http://www.mail-archive.com/debian-live-de...@lists.alioth.debian.org/msg02852.html
Bye,
--
intrigeri <intrig...@boum.org>
| gnupg key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| We're dreaming of something else.
| Something more clandestine, something happier.
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
