Previously, Canonical removed LXD from the community maintained Linux Containers project, and as in-house contributors moved on / resigned, Canonical removed their commit access to the LXD project hosted at Canonical. The original Linux Containers upstream project, along with contributors from other distributions launched the Incus project, a fork of LXD that is community maintained. LWN covered this before: https://lwn.net/Articles/940684/ Now, Canonical has relicensed LXD, including relicensing for contributions that they don't own, in addition to that, they require CLA acceptance for all contributions, which might not have been a big deal if it wernen't for their history. Some more details on stgraber's blog: https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ I suggest looking into Incus and consider switching to that as the LXD implementation packaged in Debian. thanks!
Hi Jonathan,
(Adding Free and Stéphane for their awareness)
Free and I have been working on getting Incus packaged for Debian
(see ITP#1042989 and https://wiki.debian.org/Incus). Free's getting a
couple new dependencies into the archive, and we have to update some
golang libraries, but once that's done we'll be able to get Incus
officially into Debian.
Up to this point, I had been planning to help maintain both LXD and
Incus packaging for Debian so users could easily install either
version. However, given Canonical's recent actions, I am pretty
unmotivated to continue working on the LXD packaging. Their relicensing
mess will make updating d/copyright for the next feature/LTS release a
ton of work, and while LXD is still open source, it's very much a
Canoncial-only project now with their CLA. (For the record, if anyone
else is interested in helping maintain the LXD package, please feel
free to do so!)
So, what does the future of LXD in Debian look like? After some
thought, this is what I'm envisioning:
1. Import the LXD stable-5.0 branch as a snapshot at the last commit
before the relicensing announcement (upstream commit 1364ae4: "Merge
pull request #12652") to get the last 5.0 LTS fixes/changes released
under Apache-2.0. Importantly, this will pull in the import path
changes when LXD was moved into Canonical's group on Github, which
`lxd-to-incus` is expecting.
2. Upload this snapshot version of LXD to unstable, with lots of
documentation about LXD likely not receiving further updates in Debian,
and to consider switching to Incus.
2b. As part of that upload, introduce a bin:golang-github-
canonical-lxd-dev package to facilitate building Incus.
3. Finish getting Incus packaged and into an equivalent shape as the
current LXD packaging. Also make sure migrations from LXD to Incus work
smoothly on Debian.
4. When Incus is sufficiently "mature" (either version 1.0 or we feel
it would be proper to include in a stable Debian release), if no one
else has expressed interest/willingness to maintain LXD's packaging in
future Debian releases, we can modify src:lxd to no longer ship any
binaries. Rather, it would then serve as a transitional package to
src:incus for the bookworm -> trixie upgrade cycle. The only "real"
binary package left would be bin:golang-github-canonical-lxd-dev, for
use by Incus.
5. After the trixie release, file a RM bug for LXD.
As for a timeline, we're roughly a year out from the trixie freezes
starting, so that's how long we have to complete the LXD -> Incus
transition for Debian. The alternative would be trixie shipping with a
pretty old version of LXD, which I would like to avoid if possible.
Other thoughts or opinions?
Mathias
Hello Mathias, thanks for the thoughtful write-up. I'm pretty much on board with everything you said. The only detail I'm not totally sure about is whether it would actually be beneficial to have trixie ship LXD 5.0 (at commit ^1364ae4). It's true that it'd be an out-of-date LXD, but it might be handy for folks upgrading from bookworm and not wanting to contextually migrate to Incus, but rather leave that as a separate step later down the road. It's kind of a minor point, and something that I believe won't be such a big deal in practice. So I'd be also perfectly fine not shipping the LXD binary at all in trixie. Free Mathias Gibbens <gibmat@debian.org> writes:
Currently lxd-to-incus looks for the existing running LXD daemon to validate the user configuration ahead of migrating the data to Incus, that's why we need the LXD Go package for it, we actively interact with the LXD API before shutting it down for the migration. So if you want to get rid of LXD in Trixie, you're going to want to run the migration tool from preinst which doesn't seem ideal. Or at least put in a debconf prompt to force the user to go and run the migration logic before being allowed to continue with their system upgrade. An alternative is to turn the lxd and lxd-client packages into orphans, so they can still be on the system and running when the user installs Incus and runs the migration tool. Downside of this approach is that the user may not be aware of this situation and as those binaries wouldn't be in the archive anymore, there's no way for them to pull incus onto the system. Stéphane
Hi Matthias Thanks for the details and thoughtful synopsis! Yep, there's a bunch of things to still figure out, and a lot can still happen in the next year, but in general it all seems like a general good direction for now. thanks!
Thanks, Free and Stéphane. Based on your comments, I think the best path forward will be to keep LXD packaging as-is for the trixie release, although its version will be stuck at the 5.0 LTS snapshot unless someone else steps in to further update it. I don't want to try to do any potentially tricky transition from LXD -> Incus right at system upgrade time that depends on interacting with a running daemon. But we can add a NEWS entry or similar to LXD's packaging informing people they should migrate to Incus prior to trixie+1 (forky) when LXD would be removed from Debian. Mathias
Hi Jonathan, Canonical. It's unclear to me what you refer to as "removed their commit access" because, per policy, nobody can directly push to the main branch. Everything has to go through the formal PR and review process and that's true for everyone, Canonical employees (like myself) and others. That's something Stéphane was aware of and he played along as can be seen by the few PRs that happened after his resignation: https://github.com/canonical/lxd/pulls?q=is%3Apr+is%3Aclosed+author%3Astgraber Each of those PRs were accepted and merged and we were happy to see such collaboration taking place. Regards, Simon
Earlier today I uploaded what I expect to be the last significant packaging work for LXD that I will perform. The snapshot version of LXD appears to work correctly in sid, and I only anticipate making small tweaks if needed in advance of the trixie release next year. Referring to my email on 2023-12-13, steps 1-3 are now complete. Incus is available in testing & sid, and has feature parity with the version of LXD in Debian. Barring work by another motivated individual, the current plan is to ship the snapshot version of LXD in trixie while encouraging people to migrate to Incus sometime during trixie's lifetime. Once sid opens up following the trixie release, if there haven't been any significant changes, I plan to either modify src:lxd to only produce bin:golang- github-canonical-lxd-dev if Incus still depends on it to build the `lxd-to-incus` binary, or file a RM bug to totally remove LXD in forky. Mathias
Dear submitter, as the package lxd has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1110735 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)