(huge) Ruby packaging changes

[Jeroen van Meeuwen]

On 12/22/2009 06:36 PM, Ville Skyttä wrote:
> On Tuesday 22 December 2009, Jeroen van Meeuwen wrote:
> 
>> - Use the alternatives system to point to one stack or the other for the
>> system default stack (think standalone applications).
> 
> Not that I'm anywhere near an expert in ruby matters, but I have some (bad) 
> experience with alternatives, so:
> 

Neither am I an expert in Ruby, I'm just the maintainer of the package
(partly in company time, which is just wow!). My primary point was to
have the switching of stacks be available for standalone applications
(such as puppet, facter or other Ruby programs installed in
%{_bindir}/%{_sbindir}) that use #!/usr/bin/ruby, so that we don't have
to create a specific version of all those programs for each ruby stack,
and the user could choose - but shouldn't have to.

> If this means running different individual applications with different 
> stacks/stack versions, I strongly suggest reconsidering using the alternatives 
> system for that.  Alternatives is for (easily) changing the system default 
> stack, not at all for changing per-application ones.

Being able to switch to a different stack would only be supported on a
per-system basis, but of course a single program can
#!/usr/bin/ruby-1.8.6 if it really wanted to.

FWIW, the ability would primarily be intended to be available for
developers.

  And getting it right is
> not an easy task.  FWIW in fact I'd recommend not doing any alternatives stuff 
> unless there are very strong, valid reasons for doing so.  We have an example 
> with the current Java alternatives system in Fedora which in my opinion no 
> longer has any real benefits but rather has a negative net effect and it'd be 
> good to start planning for getting rid of it altogether.
> 

The beast that is Java ;-) A very successful example where alternatives
is used heavily is of course a system's mail stack. I think it can be
done right, but the question is how.

> On the other hand, if I got your intent right, environment-modules might be 
> something to look into here.
> 

Care to explain the term environment-modules for me please?

-- Jeroen