Multiple versions [Was: "In Fedora" or "For Fedora"...]

[Bryan Kearney]

Fernando Nasser wrote:
> Bryan Kearney wrote:
> (..)
>>
>> This may be a big can-o-worms.. and if so I apologize, but is there a 
>> thought to support multi-versions jars? I could see a scenario where 
>> xerces 2.8.X is a stream (2.8.1 and 2.8.2) installed at the same time 
>> as xerces 2.9. The value being that I guess the issue is over major 
>> releases, not minor ones. The downside being I am sure this is 
>> verbotes in some fedora packaging way.
>>
> 
> Hi Bryan,
> 
> This is an old discussion, so that can of worms has been opened many 
> years ago, don't worry.
> 
> The whole purpose of a "distribution" (like RHEL, Fedora, Suse, Debian, 
> JPackage, etc.) is to find a set of packages that interoperates, ideally 
> resulting in one version of each.  The single version facilitates 
> maintaining, specially security fixing.  It also prevents conflicts by 
> accidentally loading two different versions, compiling with one and 
> running with another etc.
> 
> This said, sometimes exceptions have to be made.  Sometimes you'll see a 
> "compatible" library in Linux.  Similarly, sometimes JPackage (or RHEL, 
> or Fedora) releases a versioned package to cope with some unsolvable 
> situation.  This is treated as exceptional cases and usually done for a 
> limited time (until the dependencies can be moved to the same version).
> 
> I call these packages "legacy" and "progressive".  For instance, if the 
> maistream version of xerces is 4.7.1, our xerces-j2 RPM will be at 2.7.1 
> and we'd produce a "progressive" xerces-j282 package as a last resource. 
>  Please note the "last resource" ;-)
> 
> In a few cases we have packages that are meant to be installed in 
> parallel, like the tomcat ones as people need to migrate applications 
> between major versions and usually do it a few at a time.  So we have 
> "tomcat5" and "tomcat6" at the moment.  But this is a service, not a 
> library.

I figured as much.. but there are always valid cases (e.g. the kernel 
supports this). It seems like one instance of a library is better then 
many applications packaging the library. Perhaps the history of Java 
(and ruby) would warrant a pattern for distributing various versions.

-- bk