On Sun, 2023-10-08 at 12:19 +0100, Free Ekanayaka wrote: > 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?). 31/35 of the rdeps of golang-github-checkpoint-restore-go-criu build fine with v6.3.0 from experimental -- the big blocker is runc. Its most recent release (1.1.9) still depends on v5, although in the upstream main branch it's been switched to v6. Given that runc is a fundamental container library, I'll want to confer with the Go Packaging Team on how to move forward with this. (And LXD currently has a patch to revert the simple use of go-criu, so when v6 lands in unstable that's a simple thing to remove.) > 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. Fine by me -- for a brand new package there doesn't seem to be much reason to first target experimental, in my opinion. > Once Incus 1.0 LTS is out we could opt for uploading only LTS updates > to unstable and development releases to experimental. That's the mental idea I've had for LXD as well, although I haven't actually done that yet. One of the tricky things would be managing two distinct upstream branches (upstream-lts and upstream-dev maybe?) and then merging Debian-specific packaging changes from unstable <-> experimental. > > 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 [my] 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. With my DD hat on, I don't want to artificially hold back the version of LXD in trixie solely to make life easier for Incus -- especially if there's a 6.0 LTS release out with plenty of time before freezes start. Doing so would be a disservice to users wishing to run LXD and have the latest LTS release available in trixie. I know there will be a growing delta between LXD and Incus as time goes on, but I would also suspect Incus will want to support migrations from newer versions of LXD as best as it can. > > > 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. Looks like you've picked an initial release version of 0.17.7, so I guess that side-steps the epoch bump issue in Debian's packaging, but I don't know about resetting the .so version back to zero. Is there anything in Policy about a "backwards" transition? While there wouldn't be API compatibility, this would introduce two different "libraft.so.0" files into the archive. (And a future ".so.1" and ".so.2".) Maybe we could find another C library that changed its upstream to see how they handled it? Mostly I just don't want to accidentally cause a (subtle) mess somewhere down the road. This evening I created an initial wiki page as well, which at the moment is just tracking some of the remaining dependencies for Incus' packaging: https://wiki.debian.org/Incus. Mathias
Attachment:
signature.asc
Description: This is a digitally signed message part