On 05/23/2015 10:15 AM, Adam Burns wrote:
> Hi anonym,
>
> On 05/23/2015 09:09 AM, anonym wrote:
>> On 05/22/2015 01:31 PM, Adam Burns wrote:
>>> I've taken a very quick look at this.
>>>
>>> As the ticket #8086 suggests, it is an issue in the way Rake is used
>>> with a "Monkey-patched" Vagrant to build TAILS.
>>
>> The monkey patch is against *Vagrant*, and has nothing to do with Rake.
>> IIRC newer versions of Vagrant has built-in authentication of the boxes,
>> so that patch can be dropped.
>
> Yes, understood.
>
>>> Although the devs are keen to move to some other tech (Docker was
>>> mentioned), I'm looking at removing Rake (and thus the Vagrant library
>>> calls) from the build process if relatively easy to do so.
>>>
>>> I suspect rake was used to front end Vagrant in earlier days when
>>> perhaps Vagrant was less complete, but from quick examination, I don't
>>> think Rake is required now (nor I suspect the patching). It would
>>> simplify things enormously and bring wider Vagrant version compatibility
>>> across (including non-Debian) build OS environments.
>>
>> For the list of issues we have with Vagrant, see:
>>
>> https://tails.boum.org/blueprint/replace_vagrant/
>
> Also looked at that & related https://labs.riseup.net/code/issues/7527
> some time back. Most of the issues appear to be solved except for the
> library calls in the rakefile(?)
Please look a bit closer. Beyond importing some constants, we hack in
some stuff for backwards-compatibility with older versions of Vagrant
(see more about this issue below), but there's nothing interesting there
to be concerned about (unless I'm mistaken -- please enlighten me in
that case).
> Both Vagrant & vagrant-libvirt (installation through available though
> vagrant) have matured to some degree. Qemu/KVM and VirtualBox images can
> be built in parallel, or on choice of provisioning environment from a
> Vagrantfile.
Ok, that sounds great! However, before I lost hope about Vagrant as our
"official" build tool, my impression was that they as a project were
moving things too fast, not caring much about backwards compatibility
(including plugins, like vagrant-libvirt hard-depending on
ever-increasing versions of base Vagrant), and making it very hard to
support different versions of Vagrant at the same time. Hence our hope
to support Debian stable + Debian testing + Debian sid + latest Ubuntu
LTS + Ubuntu current (if not LTS). Also, it looked painful
maintenance-wise (and has proved to be so). Perhaps it's better now, but
it's not clear to me. Lastly, from our bluepint: "Vagrant hasn't been
actively maintained in Debian for a while. It'll be part of Jessie, but
that was by a very short margin", which is problematic from Tails'
perspective.
> But granted my current experience has been with veewee, Vagrant, ansible
> and VirtualBox/Qemu/KVM so may not be entirely appropriate here.
It sounds relevant. Patches are certainly welcome to improve the current
situation. Even if "we" (the "core" developers, whatever) move towards
docker it wouldn't hurt to also keep Vagrant (with the Virtualbox
backend, and preferably with Libvirt too) as an alternative if someone
is committed to maintain it in Tails. And to make sure Vagrant is
well-maintained in Debian.
However, it's a bit painful that veewee (and other stuff in the Vagrant
world we need?) isn't packaged in Debian. If "we" move to docker, it'd
be nice if there was a tool which could convert the docker image we will
provide into a Vagrant box.
> I still hope to put in small amount of time to at least strip rake out
> of the mix to then suggest/assess what may be possible after that :)
The current Rake logic is quite nice, IMHO, and I think you must have
misunderstood something about the whole situation. Rake is nothing else
than a Make-like system, and we don't do anything crazy with it. I
wouldn't be surprised if we end up adapting our current Rakefile to use
docker in case we move to it.
Cheers!
