On 07/05/2012 11:05 AM, Stephan Kulow wrote:
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
Chef upstream introduced their new Omnibus Chef packaging  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?
-------- Original-Nachricht --------
Betreff: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard:
declined by coolo
Datum: Thu, 5 Jul 2012 08:27:45 +0000
Antwort an: coolo(a)suse.com
State of submit-request #127033 was changed by coolo:
review -> declined
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
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org