Hi, On Thu, Jan 10, 2013 at 06:55:47PM +0000, Adam Spiers wrote:
Ralf Haferkamp (rhafer@suse.de) wrote:
On Thu, Jan 10, 2013 at 11:52:24AM +0000, Adam Spiers wrote:
Ralf Haferkamp (rhafer@suse.de) wrote:
On Thu, Jan 10, 2013 at 10:34:19AM +0000, Adam Spiers wrote: [..] I stopped adding all the gems to BuildRequires, as they are not needed for building the package. As Josef noted bundle install does not need to be called during the build. (It will be implicitly called, when starting the app for the first time though.)
Yeah, but doesn't that break the guarantee described above? which slightly worries me.
Don't we run our tests based on the packages from the ISO (+ probably the update channels). I think that provides a similar guarantee, right?
Only if we did every single bit of development and testing against packages from ISOs. Enforcing that sounds like a bad idea to me. I'm pretty sure James would agree, at least :) Not from the ISOs, but probably from the systemsmanagement:crowbar:2.0 channels. If you install all the require gems (not the crowbar-* packages) on your development machine from there before running gem install, you'll get very close (close enough?). Adding those packages to James' development image in Studio should be easy enough. And packaging-wise we are now pretty close to have everything we need in s:c:2, I think.
This is probably getting a little off-topic here now. Should we switch to somewhere else?
It should however be possible to create "-devel" and "-test" subpackages that just add the dependencies for the respective Gemfile groups. BTW, I created rpm for most of the devel and test dependencies in home:rhafer:branches:systemsmanagement:crowbar:2.0 while experimenting with the packaging.
Cool, I like that subpackage idea a lot. If it's not a lot of work to finish packaging all the dev/test gems, then Gemfile.lock could be created at build-time and we could preserve the bundler guarantee, which IMHO would be better.
That would bring back a pretty long list of BuildRequires, with all it's drawbacks. (much larger buildroot, longer build times, more rebuilts).
... but only for a single package: crowbar-barclamp-crowbar, which is already a pretty lightweight. But as Ladislav and Josef already mentioned we'd have to regenerate Gemfile.lock on the installed system everytime a dependency get's updated. So generating it during buildtime is pretty much a wasted effort. IMO the only real alternative would be to go down the "bundle package" path.
Addtionally I think we would still need to fiddle around with the Gemfile, because of the ruby18 (rcov) vs. ruby19 (scov) problems I mentioned above.
Yeah, that gets ugly.
I'm not sure where the break-even point is on the cost:reward ratio though.
Me neither. I would rather not spent much more time on this currently.
Right, I think we have already wasted a lot of time shoe-horning gems into rpms when they don't naturally fit :-/
-- Ralf -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org