On Thu, Feb 01, 2007 at 08:39:38AM +0100, Ralf Corsepius wrote:
On Thu, 2007-02-01 at 07:30 +0100, Axel Thimm wrote:
> On Thu, Feb 01, 2007 at 01:37:53AM +0100, Ralf Corsepius wrote:
> > On Wed, 2007-01-31 at 11:52 -0600, Jason L Tibbitts III wrote:
> > > >>>>> "RC" == Ralf Corsepius
> > >
> > > RC> On Wed, 2007-01-31 at 10:12 -0600, Tom 'spot' Callaway
> > > >> The Java packages in Fedora which originally come from the
> > > >> repo are the only packages which fall under this exception. And
> > > >> those packages will always fall under this exception, forever
> > > >> ever, amen (or until something dramatic changes).
> > >
> > > RC> So Fedora will never have java packages of its own and depend on
> > > RC> jpp?
> > >
> > > I'm having trouble understanding how you get from spot's
> > > above to your conclusion.
> > >
> > > There are some packages which come from jpackage and there are some
> > > that don't.
> > Then you might be able to explain why
> > * compatibility to packages from a 3rd party repo such as jpackage are
> > of any importance to Fedora.
> > Except that people ARE mixing jpp-packages with Fedora, just like they
> > do with freshrpms, atrpms, livna, dribble and many others I don't see
> > any difference.
> I don't think it's bad that Fedora cares about compatibility with 3rd
> party repos,
Neither do I.
> in fact I wish that this kind of mutual cooperation
> rather extends.
Exactly this is the point, I am asking: Why explicitly care about jpp?
OK, sorry I misunderstood you completely, I read your comments like
criticism for cooperation.
I can only guess about why jpp is treated "better" than other repos:
o one needs to start somewhere
o java is a key technology also required for RHEL, so there is vital
interest in RH for it.
o less patent encumbered/closed source parts than other repos
o good quality packaging
If I didn't knew better I'd add
o good cooperation with the 3rd party maintainers
but according to some of Jesse's comments this seems to be less the
case (or was, it may have improved since).
Axel.Thimm at ATrpms.net