Name and package confusion between lxc and lxd

After reading this post plus all the discussion around people confusing lxc and lxd and after struggling myself to distinguish between the two, please allow me to make a suggestion as to why.

First, lxd depends on lxc libraries. On some distros (such as Gentoo, my home distro, which compiles every package) you have to install the package in order to get the libraries. So already there, it’s impossible to follow the advice “It’s generally a bad idea to mix and match LXC and LXD on the same system, in my opinion, because you are likely to get confused, or LXC and LXD might get themselves confused with sharing resources like namespaces, etc. I am not aware of any good use case for using both, so you should really decide on which one to use, and stick with it.”

Second, the choice of names for the command-line tools in lxd is unfortunate. We have ‘lxc- <function’ in lxc, and the command line tool ‘lxc <function’ in a package called lxd (which also happens to have a command-line tool called ‘lxd’!). Worse, the functionality is often very similar. I understand the thinking that went behind the naming (i.e. ‘client vs. daemon’) but it does not look like much thought went into avoiding name collisions with the established package.

Given this, is it really surprising that people confuse the two?

I know making naming changes in software projects is like turning a container ship. But perhaps we could think about consolidating lxc and lxd in a monolithic package in future, as it’s not clear what benefit keeping them separate has, and in any case, for some distros, the dependency of lxd on liblxc makes keeping them separate in any clean, supportable way almost impossible.

Hi!

In Gentoo, when you only install the lxd package, does this pull only the liblxc library for its own use and avoid LXC (aka lxc-create, etc)?

Also, it is possible to install snapd on gentoo, then install the snap package of LXD. This gives you access to LXD 2.0.x, 3.0.x and 3.14.

Hi simos,

because Gentoo’s package manager portage compiles all packages, Gentoo doesn’t separate library packages (unless the package contains only libraries).

It’s theoretically possible to separate them out. The determining factor is the way upstream packages are packaged. If the library isn’t separate upstream, then it’s not treated as such by Gentoo, either.

So app-emulation/lxd pulls app-emulation/lxc as a dependency.

I am not familiar with Gentoo.

If there is a common library, let’s say, libpng, that is used by quite a bit of applications, does each application pull in their own copy of libpng?

liblxc should be a library package, and the implementation LXC should be separate from the liblxc library package. Initially (pre-2014) they were together, but with the advent of LXD, they should now be separated.

Gentoo builds everything from source by pulling it from the upstream project in whatever form it is provided, configuring and building it locally.

libpng is its own package: https://packages.gentoo.org/packages/media-libs/libpng Other packages which need libpng would pull it in as a dependency.

How is liblxc provided by the Linux containers project? Does it have its own tarball, or is it part of the LXC source?

There is https://gitweb.gentoo.org/repo/gentoo.git/tree/app-emulation/lxc/lxc-3.1.0-r1.ebuild
and https://linuxcontainers.org/lxc/downloads/

That is, the lxc source tarball for liblxc also adds the command-line tools.
But to compile just the library and avoid the command-line tools, you would need to --enable-tools=no.

1 Like

Hi simos, thanks!

That makes it simple. The configure switches can be set with via USE flags in the ebuild. (The current ebuild does not recognize the --enable-tools switch.)

I’ll see about updating it.

Ok, I updated the ebuilds and have filed a bug report: https://bugs.gentoo.org/688818

1 Like