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 <gib...@debian.org> writes: > 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
