search

ynniv / vagrant-opengenera

Convenience scripts to run Open Genera on Mac OS X or a modern Linux.
https://github.com/ynniv/vagrant-opengenera
290 stars 47 forks source link

update to support recent versions of virtualbox, vagrant and veewee #2

Closed kevinbirch closed 11 years ago

kevinbirch commented 11 years ago

These changes were necessary to get this to work on my system (MacOS 10.7) using the latest versions of Virtualbox, vagrant and veewee. I'm not sure if they will all be compatible with other systems but there are a number of small fixes for the various issues I encountered. I suspect that some bit-rot has crept into the committed configuration.

ynniv commented 11 years ago

Committing the box definition was a mistake on my part. On my computer there is no difference between definitions/ubuntu-8.04.4-server-amd64 and the template that comes with veewee. Have you made your own changes to the template definition?

I would like to take the changes to 

.gitignore
Makefile
cookbooks/opengenera/recipes/default.rb
Vagrantfile

except that I would restore to Makefile:

vagrant basebox define -f $(BOXNAME) ubuntu-8.04.4-server-amd64;

I would ignore definitions/opengenera-ubuntu-8.04.4-base, unless there are important changes from the current veewee ubuntu-8.04.4-server-amd64 template.

kevinbirch commented 11 years ago

Actually, I think committing the definition was a good idea. I did have to change the postinstall.sh quite extensively, as it was out-of-step with the more recent definitions for Ubuntu boxes (11, 12, etc). I recommend keeping this, as the definition that is being distributed won't work (VB guest kernel module build is broken, etc).

There are two very important changes to 'cookbooks/opengenera/recipes/default.rb':

  1. add curl to the list of packages installed (along side vnc, etc), as this is not installed with the base system
  2. make sure snap4 download goes into the /vagrant directory (without adding a 'cd /vagrant' it lands in the root dir)
ynniv commented 11 years ago

If we keep a local definition, it will just go out of date next time veewee has a breaking change. I checked an experimental ubuntu-7.10 definition in the repository, but the goal is always to have changes accepted by the upstream project. Perhaps the makefile should have a rule to create a definition from the base template, with a note in the README that a possibly more up to date definition can be found on your fork of veewee?

Your recipe changes are all good and will be accepted.

kevinbirch commented 11 years ago

I understand what you mean about the definition, but it looks like the Ubuntu 8.x definition is very stale. I expect that to be the case with such old OS versions. I guess part of the answer is to submit an update of the definition back to veewee. That would address the issues that exist now, but given that it doesn't seem to be maintained, it could happen again for future users. Thus: back to square one.

AFAIK, the definitions are supposed to be a starting point that you can work with, not really canonical thing. Given that, keeping a local version that is known to work would be faster to address issues with in the future. This way users don't have to wait for veewee definitions to be updated to get this to work for them. That introduces a two step process to fix these issues though: 1) fix the local definition for the user, 2) try to push the updated definition into veewee's upstream.

With such and old definition, this project may become the de facto maintainer! So that folks aren't surprised by breaking changes in the toolchain, a note in the README with the last tested tool versions could be helpful.

ynniv commented 11 years ago

I've merged this pull request, but also changed the Makefile around and switched to the ubuntu-7.10-server-amd64 definition that I completed. Let me know if this works for you.

kevinbirch commented 11 years ago

Sure, I will git it a try.