RPM and GEMS conflict of interest

[Mamoru Tasaka]

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

>
>>>
>>> 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.


> 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