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
