Hi Michal, Firstly thanks a lot for sharing your thoughts! Michal Vyskocil (mvyskocil@suse.cz) wrote:
On Thu, Jan 24, 2013 at 07:32:11PM +0100, Adam Spiers wrote:
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.
Yeah I see a lot of parallels too, that's why I added a section at the end of the page for comparisons with other languages. I think 100% is maybe a bit high though ;-) e.g. I guess Java does not have the ~> "pessimistic" version operator, and Bundler works differently to maven. [snipped]
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
These are good points - please add them to the disadvantages list on the wiki page!
* 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
That sounds like a strange possibility but I can't say you're wrong.
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.
I think you misunderstood the statement:
Just don't call it a zypper fault, because it is not.
I didn't call it a fault ;-) But it is a limitation. It's a deliberate feature of zypper (see below).
Really, there is nothing in rpm/zypper prevents you to do so.
In rpm there is nothing. In zypper there definitely is. I am not talking about overlapping files, I am talking about two versions of the same package, e.g. rubygem-rails-2_3-2.3.9 rubygem-rails-2_3-2.3.11 Unless you change multiversion settings inside /etc/zypp, there is no way to install these together using zypper. That's why I said "by default". grep for 'multiversion' in /etc/zypp/zypp.conf and you will see what I mean. My suggestion in the wiki page was to add an entry to /etc/zypp/multiversion.d just for rubygems, but some people don't like that because there is no known solution for clean removal of unused old versions of gems. So different versions of the same gem could accumulate over time on a system. The kernel packages have the same problem, but it is a much bigger problem for them because kernels are a lot bigger than gems and /boot can easily fill up.
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.
Right - but the limitation is in zypper not rpm. [snipped]
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.
This is currently solved in Ruby by using "-1" or "-1_2" style suffixes in the Name: field of the spec file: https://en.opensuse.org/openSUSE:Packaging_Ruby#Updating_gem_packages_to_a_n... but it has some known disadvantages which the multiversion approach could possibly solve. However they are corner cases so it's not currently clear whether it's worth switching to multiversion. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org