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

Fernando Nasser fnasser at redhat.com
Wed Sep 17 14:00:57 UTC 2008


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.

Regards,
Fernando




More information about the Fedora-isv-sig-list mailing list