"In Fedora" or "For Fedora", or Library versions dependency management

[Bryan Kearney]

Fernando Nasser wrote:
> Hi folks,
> 
> We are preparing a set of JBoss AS 4.2.x RPMs _for_ Fedora.  I say 'for' 
> because we have a huge (hundreds) dependency set and some of the things 
> are not suitable for Fedora.  We've been working in reducing this set, 
> solving problems but that will take a couple of years at least, and will 
> probably be for an AS 5 version, never for the 4.2.x as there is no way 
> to influence that upstream at this stage.
> 
> So we decided to have a separate repository that people can subscribe 
> their systems too and install a jbossas 4.2.x RPM with the dependencies 
> that are not on Fedora etc.
> 
> Another problem that is hitting us, and this is the main reason of this 
> message, is that the versions of some packages that are in Fedora base 
> are not compatible with ours stuff.  An App Server has to pass TCK 
> certification and has too many component interactions end up requiring 
> very specific versions of the libraries.  We are having to add some 
> hacks to our package to work around that.  Some cases we can solve by 
> upgrading the package in the next Fedora base, *IF* that dosen't break 
> something else that depends on those libraries and is in Fedora already. 
>  Some others we will keep bugging JBoss AS maintainers to upgrade in 
> some new release.  Some we have a 'versioned' package that installs in 
> parallel.  Other just can't be helped.
> 
> This problem of conflicts of dependency version requirements happens 
> even between our products.  We have created a scoreboard with versions 
> of the libraries we need so we could negotiate, among all projects, the 
> versions we will be use in ALL products.  But it is not easy, there are 
> cases which are very difficult to solve -- you either break one or the 
> other, backporting is difficult etc.
> 
> My point is, the more packages we add to the Fedora base the worse it 
> will be for us to agree on the versions of these.  So this would 
> indicate that the "for Fedora", as opposed to "in Fedora" approach 
> should be considered by all.
> 
> On the other hand, each of us having a different set of libraries in our 
> own repositories will make it difficult for people wanting to install 
> more than one.  A solution for this would be for us to foresee possible 
> cases where interoperability is desired and work out the dependency 
> problems just between those ISV products involved.
> 
> Another thing, even if we go to a "in Fedora" as the preferred method, 
> we still can use the "for Fedora" approach as a intermediate state, 
> before all dependencies needed by some product exist in Fedora.
> 
> One of our possible solutions to make our JBoss AS RPM set available is 
> release it in JPackage.org.  They have mirrored repositories and there 
> are distro specific repos, in addition to the generic repos, so our 
> modifications for Fedora can be uploaded to their fedora-9 repo.
> 
> Of course, if we all decide to make things available from JPackage, the 
> dependency conflict will move there.  But JPackage wants to have a 
> 'base' repo with additional (and optional) repos for some major 
> components like App Servers, so one can decide if they want, for 
> instance, JOnAS or JBoss, and get the appropriate dependencies.  This 
> added to the yum priority plugin turns in a very flexible setup.
> 
> 
> The above looks more like a brain dump, sorry.  I just came back from 
> vacations and I am traveling for a meeting next week, so time is scarce.


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.

-- bk

-- bk