[opensuse-factory] Rethinking packaging vagrant: Build for multiple ruby versions (almost) like a normal rubygem
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: home:ojkastl_buildservice:Vagrant 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, Johannes
Hi Johannes, Thanks a lot for looking into this, I know vagrant packaging can be quite a pain :-) I took a quick look at the changes and overall they look good to me. On Thu, Sep 14, 2017 at 10:38 PM, Johannes Kastl <mail@ojkastl.de> wrote:
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?
Did you actually get to try installing plugins?
Yesterday (I hope) I got the builds working:
home:ojkastl_buildservice:Vagrant
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... ;-)
Should we rather branch off precise versions of the rubygem plugins required by vagrant? It would make it much more resilient against updates. Thanks, Robert -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Robert, On 15.09.17 09:43 Robert Munteanu wrote:
Thanks a lot for looking into this, I know vagrant packaging can be quite a pain :-)
No comment.
I took a quick look at the changes and overall they look good to me.
Thanks.
Did you actually get to try installing plugins?
Not yet, not.
Should we rather branch off precise versions of the rubygem plugins required by vagrant? It would make it much more resilient against updates.
Yes, that would be a very good idea. I'll try to tackle this next week. Johannes
participants (2)
-
Johannes Kastl
-
Robert Munteanu