Anthony Green <green@...> writes:
FC5 has been kind of frustrating from a libgcj perspective.
We've had to
wait extra-long for new gcc RPMS in order to get critical libgcj fixes
out (for instance 4 or 5 weeks to get gc deadlock update out). I know
people have talked about separating libgcj from gcc in the past. I
don't know those conversations ever ended, but it would be really nice
if we could do something for FC6.
I think the simplest approach would be for jakub to continue building
gcc RPMS as is (including building libgcj and running gcj testsuite),
but then delete libgcj after install and don't build the libgcj
sub-packages. The gcc/libjava directory would still be part of the gcc
SRPM and would get tested as before.
Then we could simply maintain a separate SRPM for libgcj, and not be
shackled to the gcc update schedule. The SRPM would only have to
contain the appropriate target directories, and we could incorporate
mauve testing into the release process.
I think this will be particularly important if we manage to get
something like gcjwebplugin with the new whitelist feature into FC6.
We may want to push out GUI and security updates on a much more frequent
basis than is reasonable for gcc.
Comments?
Just to gibe som input from someone independent:
Debian does something like this since some time. We have two source packages,
gcc-4.1 and gcj-4.1. The first builds and packages all of GCC except Java. The
second one builds C/C++/Java and packages only the Java parts. this works quite
good. We take care that both source packages are from the same upstream sources
but its easily possible to add patches and bug fixes to one of the packages and
just rebuild it.
The gcj-4.1 source package builds the binary packages gcj-4.1, gij-4.1, fastjar,
libgcj7 libgcj7-dev libgcj7-dbg, libgcj7-awt, etc.
Cheers,
Michael