* Jeremy Katz <katzj(a)redhat.com> [2008-03-28 14:29]:
On Fri, 2008-03-28 at 14:23 -0400, Deepak Bhole wrote:
> * Tom spot Callaway <tcallawa(a)redhat.com> [2008-03-28 12:55]:
> > On Fri, 2008-03-28 at 09:50 -0400, Fernando Nasser wrote:
> > > We had agreed on an "exit clause" of dropping this when the
RPM/yum
> > > Capabilities (?) feature became available to replace the deprecated
> > > Groups, so we could mark packages with various attributes like
> > > "Java",
> > > "JPP" etc, and select them at will in all sorts of operations.
> >
> > This could just as easily go in the "Group:" tag, and not complicate
the
> > n-v-r.
> >
>
> No easy to sort with that though. With the release having jpp in there,
> one can just do rpm -qa | grep jpp
>
> As for the reason why sort is needed... well, Java is sort of a special
> case in that it is the only set that has all packages available from a
> different vendor. So if someone wants to replace the Fedora Java stack
> with the JPackage Java stack or vice versa, they need to be able to
> easily find out the set..
This is a pretty silly line of reasoning. If people are replacing the
entire stack, then _something_ is being done wrong.
Either we're
a) providing an adequate and effective Java environment (... which is
what I think we're doing) in which case, we don't _want_ our users going
off and replacing things wholesale like you're saying.
b) Or we're not. In which case, we should stop sucking and fix it.
It is not a matter of sucking as much as a matter of completion. In my
previous mail I stated this: A majority of our Java stack is just
indirect dependencies of Eclipse and Maven. JPackage on the other hand
has a lot more packages, many usable directly by the user.
In an ideal world, users would be able to mix and match packages from
Fedora and JPackage. However, that is not always acceptable to users.
For example, Fedora natively compiles most of the Java packages, has
patches to make things build with gcj (com.sun.* packages for example),
etc. JPackage on the other hard supports only proprietary vm's, so some
packages have different packages and may behave slightly different.
If Java gets a free ride of specialness here, then why not do the
same
when someone start
GPackage.org (with packages of all your GNOME desktop
bits!) or
KPackage.org. But we don't do that. In fact, we've
explicitly worked hard such that the KDE bits in Fedora are good rather
than having people go off and use kde-redhat (hats off to Rex for his
work here)
Because neither GPackage nor KPackage exist. JPackage existed before
Fedora did, and it's long existence is the reason it has such a large
set of Java packages. Additionally, Java is far more portable than
C/C++. A GPackage/KPackage could be more pain than they are worth, given
that different distros have different libraries. With Java, that is not
an issue ... that is what has sustained JPackage for so long.
Deepak