[DRE-maint] Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Hans-Christoph Steiner]

Control: severity 1049999 normal

Lucas Nussbaum:
> 
> Hi,
> 
> On 27/05/24 at 22:24 +0200, Lucas Nussbaum wrote:
>> Hi,
>>
>> An update on this:
>>
>> I plan to take care of the Debian vagrant package (in the framework of
>> the Ruby team, as this is currently done). I uploaded the latest free
>> version of Vagrant to unstable/testing
>> (2.3.7+git20230731.5fc64cde+dfsg-2).
>>
>> Of course help is welcomed. An easy and useful entry point is to look at
>> existing bugs, try to reproduce them with the latest version, and report
>> back.
>>
>>
>> I do not plan to package the non-free versions of Vagrant.
>>
>>
>> I also plan to continue to take care of the Debian Vagrant images,
>> including ensure that they work with the version of Vagrant in Debian.
>>
>>
>> I also looked a bit at potential alternatives. A project with a good
>> potential is Incus (a LXD fork by the original LXC/LXD main developer).
>> It is easy to install, and it provides both VMs and containers support.
>>
>> However currently it does not provide an equivalent to a Vagrantfile (to
>> describe the infrastructure to create, what to execute on nodes, etc.).
>> There's a terraform/opentofu provider, but that doesn't sounds very
>> exciting regarding complexity. I raised that topic in
>> https://discuss.linuxcontainers.org/t/incus-as-a-vagrant-replacement/19586
>> but the discussion did not go anywhere interesting.
>>
>> Maybe a third party project could create an incus frontend that provides
>> a Vagrantfile-like interface. Given infinite free time, I would likely
>> work on that. :)
> 
> Another update on this:
> 
> I worked on an Vagrant-inspired Incus-frontend, called Incant:
> https://github.com/lnussbaum/incant/
> 
> Incant is probably too new to ship it in Debian trixie, but I think that
> it can reasonably meet use cases where Vagrant was useful. If feedback
> is positive, I will package it in Debian and plan to provide it through
> backports.
> 
> But that also means that I've lost interest in maintaining or using
> Vagrant in Debian.
> Also, the HCP episode in January (see #1092987), where downloading boxes
> was broken for free versions of Vagrant for several weeks, shows that we
> should not expect HashiCorp to be extremely helpful with maintaining
> free versions of Vagrant.
> 
> I therefore think that it's better not to ship Vagrant as part of
> trixie, and am raising the severity of this bug to 'serious'.
> 
> If someone commits to maintaining it, feel free to dowgrade the severity
> again.

Thanks for all the maintenance over the years!

With F-Droid, we'll be stuck on Vagrant for a while longer.  So I figure I'd put 
my effort into maintaining the packages in Debian rather than elsewhere.  I 
recently when through all the relevant plugins (e.g. vagrant-libvirt) to fix 
bugs to they make it into trixie.

That said, F-Droid's usage of Vagrant is basically limited to libvirt.  We don't 
use it with cloud services or Docker.

In the meantime, we've completing an architectural overhaul that makes it easy 
to swap container/VM backends for our buildservers.  Right now, we support 
Vagrant and Podman.

The incident that broke downloading boxes was actually inspiring to me, because 
there was rapid cross-distro collaboration for how to fix it.  I also want to 
maintain this because I don't want to let Hashicorp win that easily.  We should 
demonstrate that free software communities won't just sheepishly go along with 
companies that build up value based on free software communities, then take it 
proprietary to cash in.

.hc