On 07/05/2012 11:05 AM, Stephan Kulow wrote:
Hi,
I declined this because IMO we shouldn't allow rails apps with bundled gems in factory. It's fine in whatever project, but there is no point in packaging gems if all apps then just call bundle package. What do you think? Does this make sense? Is that realistic?
Thanks for starting this thread - I was just about to do exactly that. :-) In this case (puppet-dashboard), the tarball is directly from upstream and contains bundled gems. It is not worth the effort to extract these gem dependencies (21 including plugins, gems and rails) and repackage them. We don't really gain anything significant and just create more work and makes things more fragile because of the complexity. For Chef packaging I went down a similar route by copying/fixing the IBS Devel:Cloud packages to OBS systemsmangement:chef (I've already talked to the Cloud team). There are now almost 60 (!) rubygems there and it took me 2-3 days to get here. Most of the time was spent checking if the rubygem I need is already somewhere in OBS, aggregatepac to it, fix spec fies, make new rubygem packages if it is not already there or if the version I need is missing, waiting for OBS to build them, fix new problems, etc. Keep repeating this until everything is green (I'm almost there...) [1]. Chef upstream introduced their new Omnibus Chef packaging [2] last week. Basically a simple bash install script that pulls down one fat rpm/deb containing all the gem dependencies. For Studio Online, we ditched repackaging gems in RPMs months ago and never looked back. Yes there are downsides (eg. we now have to install devel packages for native gems need to compile their stuff), but this saves us a lot of work in repackaging ~200+ gems (including the various versions required by the different dependencies). For Studio Onsite 1.3, we will switch to bundling gems instead of repackaging them individually. This is in agreement with the security and maintenance teams. I chatted briefly with Duncan in IRC, and it seems to me that the ideal long-term solution is for zypper to handle gems. Could be a nice hackweek project to get a prototype. For now, I think it's perfectly fine for applications/packages to bundle gems. It's essentially trading some MBs of disk space (for duplicated gems) for many hours/days of work. What does everyone think? [1] https://build.opensuse.org/project/monitor?project=systemsmanagement%3Achef [2] http://www.opscode.com/blog/2012/06/29/omnibus-chef-packaging/ Cheers, James T.
Greetings, Stephan
-------- Original-Nachricht -------- Betreff: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard: declined by coolo Datum: Thu, 5 Jul 2012 08:27:45 +0000 Von: coolo@suse.com Antwort an: coolo@suse.com An: coolo@suse.com
State of submit-request #127033 was changed by coolo:
review -> declined
Comment: this package contains copies of all gems, this is not how openSUSE packages work I think. And it requires ruby(abi) = 1.8, which does not exist on factory
https://build.opensuse.org/request/diff/127033
Source project: systemsmanagement:puppet package: puppet-dashboard revision: 1
Target: project: openSUSE:Factory package: puppet-dashboard
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org