Multiple versions [Was: "In Fedora" or "For Fedora"...]
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.
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
More information about the isv-sig