[lxc-users] The purpose of init.lxc.static

[Stéphane Graber]

On Wed, Jun 18, 2014 at 07:13:52PM +0000, Serge Hallyn wrote:
> Quoting Leonid Isaev (lisaev at umail.iu.edu):
> > On Wed, Jun 18, 2014 at 02:08:00PM +0000, Serge Hallyn wrote:
> > > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > > 
> > > > Sounds like we really want a way to detect that case and turn off
> > > > building the static init in that case.
> > > > 
> > > > The reason for the static init is to make lxc-execute work in all cases,
> > > > including cases where the host architecture doesn't match the
> > > > container's and cases where the container doesn't run the same libc as
> > > > the host (or doesn't have a libc at all).
> > > > 
> > > > LXC has fallback code to look for the dynamically linked init.lxc, so
> > > > there's no reason why the static one would be an hard dependency.
> > > > 
> > > > Serge?
> > > 
> > > Well the -lcap we can fix easily, but no -lutil?  That's a bit messed
> > > up.  So perhaps we should simply have configure.ac check for the static
> > > libraries ahead of time.  If there is no AM_FOO for that we can do our
> > > own quick test.
> > > 
> > > Leonid are you up writing such a patch?
> > 
> > Yes, if you can wait because I'll be travelling in the next 10 days and can not
> > guarantee internet access. But I still don't fully understand which static libs
> > we should check for -- only those above, or there are others planned in the
> > future?
> > 
> > Wouldn't it be simpler to make a new ./configure option, e.g.
> > "--disable-static-binaries" which disables the static build alltogether? So, by
> > default we compile init.lxc.static (and possibly other tools in the future),
> > just as before, and not break existing packaging workflows.
> > 
> > I know there's plenty of discussion how bad static linking is, but my primary
> > objection against it is maintainability of packages. In Arch we have various
> > tools to tell which binaries (and packages) link to a given library, so
> > rebuilds are straightforward. With static binaries there is no way to tell and
> > this might be a problem on a rolling release system where updates occur
> > continuously.
> 
> Yes, we don't like it either, but it's the only straightforward way of
> allowing lxc-execute in random containers without first setting up all of
> the library dependencies.
> 
> Other ideas are definately welcome.  Including "but we don't really care
> about that"

I think it's fine so long as we keep things small and simple, so drop
any external dependency outside of libc (as was suggested a few times,
the libcap one doesn't make much sense there) and have a configure flag
(with reasonable auto-detect) to turn the feature on/off.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140618/6e2c7e94/attachment.sig>