Re: Questions regarding diversion of flash-kernel while building chroot
On Fri, Mar 02, 2012 at 12:50:36AM -0500, Cody A.W. Somerville wrote:
> I was curious why it is necessary to use dpkg-divert to temporarily
> disable /usr/sbin/flash-kernel per your patch accepted to live-build
> upstream but not start-stop-daemon which is instead just moved aside
> with mv a few lines above. Is it to properly handle the case where
> the file is updated via package upgrade? If so, I assume the other
> instances like start-stop-daemon need to be fixed to use dpkg-divert
> as well?
start-stop-daemon is installed as part of the base system, before
lb_chroot_dpkg runs. flash-kernel is not, and if it's going to be
installed then it will be installed after flash-kernel. This means that
the requirements are different.
I'm not sure whether it's possible for dpkg to be upgraded in the
context of a live-build run. If it is, then start-stop-daemon needs to
be handled using dpkg-divert; otherwise, it isn't necessary.
> Additionally, I see you symlink /bin/true from outside the chroot to
> act as a dummy /usr/sbin/flash-kernel.
No, symlinks don't work that way. The result of 'ln -s /bin/true
chroot/usr/sbin/flash-kernel' is that chroot/usr/sbin/flash-kernel
becomes a symlink inode with the text '/bin/true', which is resolved at
the point when it's opened, not before. If you open
/usr/sbin/flash-kernel inside the chroot, then you'll get /bin/true
inside the chroot.
It's not possible to create a symlink that will result in the contents
of a file outside the chroot when opened inside the chroot.
> This is problematic if the (E)ABI between the host system and chroot
> system are incompatible (eg. armel host and armhf chroot) as the
> binary will not be executable and thus most likely cause the build to
> fail if flash-kernel is called. I've filed bug #661871 in Debian BTS
> regarding this.
IMO this bug should be closed as invalid.
Colin Watson [email@example.com]