Mathias Gibbens <gib...@debian.org> writes: > Control: reassign -1 wnpp > Control: retitle -1 ITP: Incus -- Powerful system container and virtual > machine manager > Control: severity -1 wishlist > Control: block -1 by 1052536 1001989 > > I'm converting this bug to an ITP, as there's clearly sufficient > interest in the packaging of Incus. Plus, it will help track any > dependencies that need to be packaged/updated for Debian.
+1, thanks. > On Tue, 2023-09-19 at 08:44 +0100, Free Ekanayaka wrote: >> The dependencies should be pretty much the same as LXD 5.16, except for >> cowsql, and for a few dependencies that actually got dropped wrt LXD. So >> that part should be relatively straightforward if you have already done >> some work for LXD 5.16. > > There are two dependencies still in progress that are needed to > properly build the latest feature release of LXD in Debian: golang- > github-grafana-dskit (ITP#1001989; it has one dependency [golang- > github-uber-jaeger-client-go] currently in NEW before I can package it) > and updating golang-github-checkpoint-restore-go-criu to v6 (currently > on v5, with a patch to undo its use in the current LXD packaging). It seems that v6 of golang-github-checkpoint-restore-go-criu is in experimental: https://packages.debian.org/experimental/golang-github-checkpoint-restore-go-criu-dev Not sure if there are blockers for it to move to unstable (maybe we'd need to drop the patch currently applied to the LXD package?). >> We were thinking more or less the same, but with a difference: what >> about uploading to Debian only the LTS updates of LXD for now (that >> means the 5.0.x releases) and start uploading the Incus development >> releases (once the first is out)? > > That seems reasonable to me. I know people occasionally ask for the > latest version of LXD, which someday I might upload to experimental on > a "best effort" basis, but the main packaging for LXD will follow the > LTS releases. Prior to Incus' 1.0 LTS release, I think it would be > great to upload development releases to facilitate testing by > interested users. Yes, agrred. Incus 0.1 has now been released, and I've updated the salsa repository accordingly. I've also switched the packaging branch from debian/experimental to debian/unstable, as actually I don't see a reason for not uploading to unstable at this stage. Once Incus 1.0 LTS is out we could opt for uploading only LTS updates to unstable and development releases to experimental. >> Once trixie gets released it would contain the latest LXD 5.0.x release >> (which upstream supports until June 2027), and the latest Incus LTS >> release. Bookworm users can upgrade to trixie and then migrate their >> deployments to Incus using the lxd-to-incus tool, if they wish to. > > Just a minor note -- if LXD keeps its established release schedule, > I'm expecting LXD 6.0.x to ship in trixie. Yes, although I would personally keep Debian's LXD at version 5.0.x for trixie and point users to the lxd-to-incus migration tool, to migrate from LXD 5.0.x to Incus 1.0.x, which should be be a superset of LXD 6.0.x. That's of course just might take, I understand that there might be interest from other DDs/users (e.g. you) to update the Debian's package to LXD 6.0.x. > We will definitely want test the transition path and ensure there's > good documentation in place for the trixie release. +1 >> As for now cowsql's raft is compatible with dqlite's raft, and I plan to >> maintain that compatibility, at least as far as the LXD+dqlite stack is >> concerned (which is what matters for Debian). >> >> What I'd propose would be to change the upstream of the libraft package >> in Debian from canonical/raft to cowsql/raft, and I could (co-?)maintain >> the libraft package as well as the dqlite one, making sure they work >> together (that might help Laszlo too, taking some work off his plate, I >> can reach out to him and ask). > > Currently in unstable there are only three rdeps of src:raft: dqlite, > golang-github-canonical-go-dqlite, and lxd. So it would certainly be > doable to switch the upstream of src:raft -- if Laszlo is open to doing > so, it should be a pretty easy transition. Probably the trickiest thing > would be the versions: I'd like to avoid a package epoch bump if > possible, and we'd also have to consider the .so versioning. Why do think an epoch is needed? I believe it can be done without epochs. Anyway, if the idea gets consenus I'll coordinate with Laszlo about that. >> It's still very early on and it's not working yet (I've mostly rebranded >> the debian/ directory of the lxd Debian source package), but it's a >> start, so perhaps we might already have something kind of working by the >> time the first Incus release is out. > > At least initially, I'd like to keep the packaging for LXD and Incus > as similar as possible. I know over time things will diverge, but for > now I think keeping the delta between packages small will be > beneficial. Yes, agreed. At the moment the incus packaging repo is most a rebranding of the lxd one. Free