Control: retitle -1 LXD licensing changes and future for Debian packaging Control: severity -1 important
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
signature.asc
Description: This is a digitally signed message part
