[opensuse-ruby] Fwd: [obs submit-request 127033] openSUSE:Factory/puppet-dashboard: declined by coolo
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? 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 -- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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
Ping, no comments from anyone? For the short/immediate term I highly recommend that we go with allowing the bundling of gems in applications. James T. On 07/05/2012 02:56 PM, James Tan wrote:
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
On 11.07.2012 14:51, James Tan wrote:
Ping, no comments from anyone?
For the short/immediate term I highly recommend that we go with allowing the bundling of gems in applications.
This ruby community is great in exchanging ideas :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Mon, 16 Jul 2012 13:33:49 +0200 Stephan Kulow <coolo@suse.de> wrote:
On 11.07.2012 14:51, James Tan wrote:
Ping, no comments from anyone?
For the short/immediate term I highly recommend that we go with allowing the bundling of gems in applications.
This ruby community is great in exchanging ideas :)
Greetings, Stephan
Well, what you ideas you expect? For me it is reinventing wheel. It is exactly same for me like discussion if we should link libraries statically or dynamic. I see there same pros&cons. And question is if we want user to get bundled apps from us ( some appliacation is so complex, fragile, that any dependency change can break it ) or if he should download it outside of distribution ( like we do now with bundled libraries, e.b. games from humble bumble, that often contain static libraries ). I see there only small difference, that more ruby library authors ignore backward compatibilty ( just my observation ), but it is not bug difference. So what we should discuss? It is clear decision what we want distribute. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 16.07.2012 13:39, Josef Reidinger wrote:
On Mon, 16 Jul 2012 13:33:49 +0200 Stephan Kulow <coolo@suse.de> wrote:
On 11.07.2012 14:51, James Tan wrote:
Ping, no comments from anyone?
For the short/immediate term I highly recommend that we go with allowing the bundling of gems in applications.
This ruby community is great in exchanging ideas :)
Greetings, Stephan
Well, what you ideas you expect? For me it is reinventing wheel. It is exactly same for me like discussion if we should link libraries statically or dynamic. I see there same pros&cons. And question is if we want user to get bundled apps from us ( some appliacation is so complex, fragile, that any dependency change can break it ) or if he should download it outside of distribution ( like we do now with bundled libraries, e.b. games from humble bumble, that often contain static libraries ).
I see there only small difference, that more ruby library authors ignore backward compatibilty ( just my observation ), but it is not bug difference.
So what we should discuss? It is clear decision what we want distribute.
OK, replace ideas with opinions in my statement. I read your mail as "if applications are as fragile as requiring bundled gems, do not distribute it" btw. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Mon, 16 Jul 2012 13:51:12 +0200 Stephan Kulow <coolo@suse.de> wrote:
On 16.07.2012 13:39, Josef Reidinger wrote:
On Mon, 16 Jul 2012 13:33:49 +0200 Stephan Kulow <coolo@suse.de> wrote:
On 11.07.2012 14:51, James Tan wrote:
Ping, no comments from anyone?
For the short/immediate term I highly recommend that we go with allowing the bundling of gems in applications.
This ruby community is great in exchanging ideas :)
Greetings, Stephan
Well, what you ideas you expect? For me it is reinventing wheel. It is exactly same for me like discussion if we should link libraries statically or dynamic. I see there same pros&cons. And question is if we want user to get bundled apps from us ( some appliacation is so complex, fragile, that any dependency change can break it ) or if he should download it outside of distribution ( like we do now with bundled libraries, e.b. games from humble bumble, that often contain static libraries ).
I see there only small difference, that more ruby library authors ignore backward compatibilty ( just my observation ), but it is not bug difference.
So what we should discuss? It is clear decision what we want distribute.
OK, replace ideas with opinions in my statement.
I read your mail as "if applications are as fragile as requiring bundled gems, do not distribute it" btw.
Greetings, Stephan
OK, my opinion is that we should consider it per project. If we allow bundled gems, then project must be enough important. I think we should have basic rule to not allow it and only if project is enough popular, important, etc then allow it. Having bundled gems indicate for me that project is badly written as it is fragile to changes in gem versions or have "bad" gems choice ( exotic gems, that use only project itself or gems that ignore backward compatibility ). Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (3)
-
James Tan -
Josef Reidinger -
Stephan Kulow