On Thu, Jan 24, 2013 at 07:32:11PM +0100, Adam Spiers wrote: > Adam Spiers ([email protected]) wrote: > > [Reply-To: set to opensuse-ruby] > > > > Hi all, > > > > After many discussions on this list, and also many internal > > discussions within SUSE, I have attempted to summarise a collective > > understanding about the pros and cons of the various strategies for > > packaging Ruby applications. > > [snipped] > > Ahem. It might help to include the link ;-) > > https://en.opensuse.org/openSUSE:Ruby_Gem_Strategies
Hi Adam, interesting reading - but this is not just about Ruby. Wearing my Java packager's hat, with just changes (s/Ruby/Java/; s/gem/jar/; s/Gemfile.lock/maven/) it 100% apply there as well. The reason why it appears more in environment such Ruby community is that it is much easier to download gem, or jar or python's egg to some dir and make it a de-facto a part of your code, than to make the same with a native library. And (I'll discuss it later) the native packaging is better researched and even solved problem. And this is even the reason why packaging of this s*** (let say stuff) is so hard, because no-one excluding few poor souls even think about component dependencies, API stability and so. Extend zypper to support installing gems directly ================================================= Note the "we" means a distributor, so someone, who will be responsible for the result. * we rely on external service - things can dissappear, or be silently changed without our control * we can't make changes or fix a bugs * we even don't know if the code have a proper license * in Java world it is common jars includes a bytecode, not a source code - but afaik nothing prevents you to publish a gem with a Ruby bytecode only So yes, this is an easy path to make a project done, but a nightmare for the maintenance. IOW: if you want to throw a result and never look back, this is the best approach. zypper doesn't support multiple versions of same gem concurrently installed by default. ==================================================================== I completely disagree with above sentence! Sorry to say it, but if you make a bad package, you'll get a bad results. Just don't call it a zypper fault, because it is not. Really, there is nothing in rpm/zypper prevents you to do so. Rpm just does not let you to install two packages at the same location. And this is very reasonable constraint, otherwise, you'll end with two packages installed according rpmdb, but only the later will be there. To make an example, I have libncurses5 and libncurses6 installed on one system and it works - zypper, neither rpm complaints and every program use the correct version of a library. And this is achieved because 1.) shared library packaging policy [1], results in packages installable in a parallel 2.) linker (ld) and loader (ld.so) and autoreqprov magic in rpmbuild. They all ensures the needed packages are installed and correct libraries are loaded. Number one is easy to achieve if you already have an automation. But writing an alternative to ld.so is tricky part, because it is not solved upstream. For python it can be probably achieved by virtualenv, but don't know Ruby in such big details - Google says there is RVM [2]. [1] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy [2] https://rvm.io/ BTW: even this does not saves you from inter-dependencies, like gem A needs gem B-v1.0, where gem C needs B-v2.0 and in some time, you'll need to use A and C together. This is to some extent solved in ld.so and ld, but I'm afraid unsolvable without a big hacking in rest of the world. Fortunately this is probably very rare issue. Regards Michal Vyskocil
signature.asc
Description: Digital signature
