Re: lsb-core problem -- package conflicts with chroot
bob@proulx.com (Bob Proulx) writes:
> I just hit lsb-core version 2.0-1 which causes me problems. I have
> not updated for a while. Testing using the latest debian-pure64.
>
> * Depend on ia32-libs on amd64. (Closes: #259976)
The LSB kind of requires biarch support and the way to formulate this
is with a Depends: ia32-libs. Nothing wrong with that.
> But I am not using ia32-libs. I am using an ia32 chroot. But now I
> am required to use ia32-libs if I want the lsb package. This breaks
> my ability to use a chroot to maintain the ia32 binaries. What was
> working is now broken.
>
> A second very annoying property is that this is a silent data
> corruption. An upgrade to the lsb package pulls in ia32-libs and this
> is installed on top of the existing chroot area, corrupting it.
>
> I see the reasoning behind someone wanting the ia32-libs package
> installed. But it is completely wrong in the chroot case. (A good
> argument for multiarch. But that is another discussion.)
>
> Of course I will now create a local no-ia32-libs package that
> conflicts with ia32-libs and will install and hold that package. That
> will prevent future accidental breakage.
>
> I am somewhat at a loss as to how to address this problem.
> Suggestions?
>
> Bob
You have installed files into a place that is not ment for you as
local admin to mess with but in the dpkg domain. That means dpkg can
break your stuff at any time, your loss. Thats just how it is. :(
Now, lets fix this. There are some possibilities:
1. Create an ia32-chrooted package
The package should "Provides: ia32-libs, ia32-libs-dev" and conflicts
with both of them. It should contain the ld.so.conf handling from
ia32-libs and some docs on how/where to setup the actual chroot. You
could even add a debconf question that mentions the documentation or
what to do that is displayed if no preinstalled chroot is found.
The package could even offer to run (c)debootstrap on install or
provide a script for it that makes all the extra changes needed,
e.g. mtab, passwd, groups, hosts, resolv.conf, ...
You could upload that to debian (via sponsor?) or we could just add it
to the amd64 archive.
2. Don't put your chroot where debian puts other things
Putting your chroot under /usr/local/chroot or /opt/chroot or
something out of dpkgs way is save. All you have to do is point
ld.so.conf there for the libs to work.
3. Create a no-ia32-libs package
The package would divert all the files from ia32-libs (and
ia32-libs-dev) allowing you to place your own files there. This
prevents dpkg from overwriting them. But every time ia32-libs changes
some filename you have to change no-ia32-libs too. So this is ugly.
I would clearly go for either 1 (package welcome) or 2 (current way).
MfG
Goswin
Reply to: