[Fedora-packaging] Java packaging guidelines draft

[Deepak Bhole]

* Jeremy Katz <katzj at redhat.com> [2008-03-28 14:29]:
> On Fri, 2008-03-28 at 14:23 -0400, Deepak Bhole wrote:
> > * Tom spot Callaway <tcallawa at 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