On Mer 27 avril 2005 10:43, Warren Togami a écrit :
Nicolas Mailhot wrote:
> On Mer 27 avril 2005 5:00, djh a écrit :
>>>We really can't ship FC4 in such a way that Sun's jre (which is
>>>feature complete today) is uninstalled seemingly without warning when
>>>gcj is not complete yet.
>>It's not just the Provides: jre causing the problem. The Sun JDK/JRE
>>rpms have a Provides: xml-commons-apis. Upgrading the Fedora
>>xml-commons-apis rpm uninstalls the Sun rpms too.
> All the various jvm packages need to have more or less the same provides
> or you can't switch them at will.
> The problem with Sun packages is they never tried to work with anyone to
> make sure their stuff works (for example they added the xml-commons
> provides without putting the associated jar in a place our scripts can
> find it, so not installing a separate commons implementation will get
> errors at tomcat startup)
Hmm, sounds like we have no options for flexibility here.
I wonder if it would be legal for us to ship a "install-sun-java" script
with Fedora that downloads their java tarballl, runs the binary (so the
user has to type "yes"), repackages it and spits out a jpackage RPM.
This would be simpler for documentation and would steer people away from
their problematic RPM. And yes I'm serious about this if it would be
Only thing I don't know is if this would conflict with our native open
That's already basically what the jpackage nosrcs do (except we start from
the jvm zips not rpms since they're the only ones available)
The problem is - we don't have any control on what Sun chooses to put in
its own packages, nor on its (dubious) reading of the FHS, so as soon
someone installs the original sun package the game is over.
(we have an adaptation compat rpm that adds the right stuff alongside the
Sun package too but it can do nothing for the the Sun provides)