Rethinking packaging vagrant: Build for multiple ruby versions (almost) like a normal rubygem

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Rethinking packaging vagrant: Build for multiple ruby versions (almost) like a normal rubygem

Johannes Kastl-2
Crosspost on factory and packaging, please reply to factory...


Good evening everybody,

over the last couple of months I have been on and off with an
alternative approach to package vagrant.

First off: This might not the bee's knees and the best way of
packaging this. I also do not want to be rude to Duncan, Robert or the
others that have taken care of vagrant so far. I just wanted to put it
out there and get some opinions, if this might be a feasible approach
for the future.

For those not familiar with vagrant's packaging, the current package
- creates a rubygem in %build and then packages it for the default
ruby version hardcoded in the spec file and
- ignore's vagrants requirement for ruby2.2 so it is installable on
Leap 42.* which has ruby2.1.

I had some issues getting the plugin installation to work, and found
some things that I (as a not-ruby-expert) thought might be because of
this 2.1-vs-2.2 thing. But how to solve this issue for Leap 42.2,
which only has ruby2.1?

Yesterday (I hope) I got the builds working:


Basically, you can install vagrant in the flavour for the ruby version
of your choice, which let's you install it with ruby2.4 on TW and
ruby2.2 on Leap. Or ruby2.3 or ruby2.5.

All dependencies that I found so far have been put into that project
and have being modified, where needed, to also build for more than one
ruby version. In my tests this worked, but then again one change
somewhere and everything falls apart... ;-)

Where possible I tried to narrow down the requirements so there should
not be any "have choice" errors. But, as each package actually is five
packages (one for each ruby in ruby{1,2,3,4,5}) with one status
(successful or failed).

Disclaimer: Due to the nature of ruby packages on the OBS it might
happen occasionally, that during updating or adding packages, some of
them might not get built for all ruby versions but are being shown as
successful in the webUI. So, in case you think there is something
missing, give me a call. (And, just to avoid misunderstandings, I
think the way to build ruby packages on OBS is pretty cunning, even if
there are corner cases now and then.)

So, I am looking forward to your thoughts and feedback.

Kind Regards,

signature.asc (900 bytes) Download Attachment