Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Mathias Gibbens <gibmat@debian.org> writes:
> 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.)
It sounds good to me to use the patch for the Incus package as well, and
remove it later on when the situation unblocks.
>> 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.
Yeah, maybe something like that.
>
>> > 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.
Note that LXD's recommended installation way is via snapd, which should
be available in Debian, so Debian users wishing to run 6.0 LTS would
have that option, albeit not "native".
That being said, I certainly understand your reasoning.
> 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.
Yeah, I think so, I'm just not sure how much that will be practically
feasible, so probably the answer is "it depends". I'll ask Stéphane too
about this. I don't think there's any certainty here, but he should be
able to provide an educated guess about whether Incus 1.0 might be able
to support migrations from LXD 6.0.
>
>> > 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.
Yeah, there was a bit of a mess in the past with .so versions. It should
have been kept to 0 all the way in the first place, and ABI compatibilty
should have not been broken.
>From now on, I'll make sure that the .so version stays at 0 and that all
releases in the 0.x series are backward-compatible both in terms of API
and ABI.
In the long term I plan to eventually have a 1.x series too, which will
likely break ABI compatibility, and require a .so version bump to 1, but
that's relatively far in the future.
> Is there anything in Policy about a "backwards" transition?
I don't think there's any hard rule, or at least I didn't find anything
specific about that in:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> 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.
As far as I can see the "libraft.so.0" file is contained only in the
libraft0 package of bullseye, and in bullseye there was no lxd or dqlite
package yet, so libraft.so.0 isn't really used for anything in bullseye.
That means upgrades from bullseye should be fine.
I realize that this is an unusual and less-than-ideal situation which
I'd otherwise avoid, but my thinking is: better to byte the bullet now
and have a cleaner management of the .so version in the future, than to
carry on some baggage.
Please let me know if I'm missing something. I could also change the
upstream .so version to 3, if there's concern about the current
approach.
> 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.
Great, thanks!
Free
Reply to: