RPM and GEMS conflict of interest

[Gilles Dubreuil]

On Thu, 2010-06-24 at 13:17 +0900, Mamoru Tasaka wrote:
> Gilles Dubreuil wrote, at 06/24/2010 10:56 AM +9:00:
> > On Wed, 2010-06-23 at 18:32 +0900, Mamoru Tasaka wrote:
> >>>
> >>> I also guess you're right and as long it doesn't break the gems as we
> >>> can still install multiple gems of different versions.
> >>
> >> Honestly saying, I also question about this statement that
> >> "we can still install multiple gems of different versions".
> >>
> >> For example rails 2.3.5 (in fact actionpack 2.3.5) can be compatible
> >> with rack ~>  1.0.0. And many people already reported that with
> >> rack 1.1.0 / 1.0.0 parallel installed, rails 2.3.5 no longer
> >> work because rack 1.1.0 is to be loaded first.
> >>
> >> So "we can install multiple gem of different versions" does not
> >> mean "they work altogether correctly". If parallel-installed gems
> >> worked, well, it is just lucky. Also I don't think that the upstream
> >> gem module developer actually guarantee that parallel install
> >> works.
> >>
> >>
> >
> > I don't understand why you're saying it's not working???
> > Maybe you had an issue on that environment?
> >
> > I've been using RoR for over a year and never had problems switching
> > between libraries (or gems version). This is rock solid AFAIC.
> > I also have a RoR application deployed on a big server farm
> > infrastructure out there (they use Debian):
> >
> > $ gem list
> > actionmailer (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
> > 2.0.5, 2.0.2)
> > actionpack (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
> > 2.0.5, 2.0.2)
> > actionwebservice (1.2.6, 1.2.3)
> > activerecord (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
> > 2.0.5, 2.0.2)
> > activeresource (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
> > 2.0.5, 2.0.2)
> > activesupport (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0,
> > 2.0.5, 2.0.2)
> > acts_as_taggable (2.0.2, 1.0.4)
> > ajax_scaffold_generator (3.1.11, 2.2.1)
> > archive-tar-minitar (0.5.2, 0.5.1)
> > auth_generator (2.0.1, 1.5.3)
> > Bloglines4R (0.1.0)
> > BlueCloth (1.0.0)
> > builder (2.1.2, 2.0.0)
> > camping (1.5.180, 1.5)
> > capistrano (2.5.1, 2.1.0, 1.4.1)
> > ...
> > rack (1.1.0, 1.0.1, 1.0.0)
> > radiant (0.6.9)
> > rails (2.3.5, 2.3.4, 2.3.3, 2.2.3, 2.2.2, 2.1.2, 2.1.1, 2.1.0, 2.0.5,
> > 2.0.2)
> > rake (0.8.7, 0.8.3, 0.8.2)
> 
> So you are just lucky and unaware of the issues.
> e.g.
> https://rails.lighthouseapp.com/projects/8994/tickets/3685-actionpack-235-gem-declares-incompatibility-with-rack-110
> 

I'm sorry but one example doesn't make the case.
This one sounds as a bug in the library as explained.

> >
> >>>
> >>> This way multiple ruby-gem rpms versions would be possible.
> >>> Actually can we do multiple rpms version without conflict?
> >>
> >> So basically I think installing multiple version is not "supportee".
> >>
> >
> > GEMs provides multiple versions, that's running and if not then it's a
> > broken case.
> > So it doesn't preclude the fact that this a service/function RPMs does
> > not provide at this stage, at least in regards of Gems.
> >
> > But more specifically the fact is:
> > "Why different versions of programming libraries could not co-exist
> > straight-out of the box on a Distro?"
> 
> See above. i.e. parallel-install of different versions is basically
> unsupported.
> 

I understand it's not supported. That's my point.

> 
> > Fedora could make that happens (especially with it's position among
> > developers).
> >
> > I'm not trying to get one to replace the other.
> > I suppose at this stage they have a different scope and therefore are
> > complementary.
> >
> > Ultimately, I'm sure RPMs could manage that.
> > This isn't already the case with old legacy compat libs for instance?
> 
> compat libs usually have libraries of different sonames and in that point
> compat libs are "different" packages. Also creating compat packages is
> _strongly_ discouraged on Fedora and unless avoidable we don't allow it
> (simply because we want to install several versions is not a valid
>   reason on Fedora)
> 
> Mamoru

I understand and respect the "not encouraged" to deploy several versions
of a same package. 
Although technically it works like in the compat libs or many other
packages like opensslX and many others apps for legacy dependencies.

Therefore having two version of JVM or JDK for instance should never be
allowed from an RPM point of view? And we we would have to rely on using
"alternatives" to create symbolic links and stub config files?

Sorry to insist but isn't up to the user/sysadmin to decide what to
install on the box? And be able to simply deploy concurrent versions of
libraries?

Regards,

Gil