Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
Summary: Review Request: libgcj - separate libgcj srpm Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: jkeating@redhat.com ReportedBy: tromey@redhat.com QAContact: extras-qa@fedoraproject.org CC: fedora-package-review@redhat.com,notting@redhat.com
Spec URL: http://people.redhat.com/~tromey/libgcj-srpm/libgcj41.spec SRPM URL: http://people.redhat.com/~tromey/libgcj-srpm/libgcj-4.1.1-20.src.rpm
Description:
This is a separate source RPM for libgcj. The idea is to allow pushing libgcj updates separately from GCC updates, enabling faster bug fix turnaround.
There's a separate patch for the GCC spec file. I've sent a version of it to Jakub, but it needs an update. This patch reduces the build requirements of GCC; for instance we no longer need gtk to build the GCC rpms.
There is a helper script in the libgcj SRPM to create the initial source tar from the gcc srpm. I think maintenance-wise the best approach is to start with the current gcc sources and then apply libgcj patchese as needed. Rebasing to a new gcc is simply and automated with the script.
With my patch the gcc spec file still builds libgcj. This lets us continue to run 'make check' to verify that compiler changes don't break the libgcj build. However, the libgcj built here has reduced functionality (e.g., no AWT peers -- this is why we can remove build requirements) and is not packaged.
With this change, fastjar and grepjar move from the libgcj RPM into the gcc RPM.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
jkeating@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jkeating@redhat.com |nobody@fedoraproject.org
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From notting@redhat.com 2006-09-29 13:53 EST ------- I presume this is targeted at FC-7?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From fitzsim@redhat.com 2006-09-29 15:58 EST ------- (In reply to comment #1)
I presume this is targeted at FC-7?
No, Jesse wanted this for FC-6.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From notting@redhat.com 2006-09-29 16:05 EST ------- Huh? It seems way late in the game for this.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From tromey@redhat.com 2006-12-18 15:05 EST ------- I'd like to request a review for this for FC-7.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From jkeating@redhat.com 2006-12-18 15:19 EST ------- With our intent to move all packages externally, can this split wait until then?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From overholt@redhat.com 2007-01-12 13:45 EST ------- It would be nice if it could happen before the split so that we can start testing the libgcj bits sooner rather than later.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From overholt@redhat.com 2007-02-14 14:21 EST ------- Is this going to happen? From my perspective, the pros/cons are:
Pros: . no need to bug Jakub on libgcj requests -> this is the biggie IMO. I know I feel bad when I want one small class library fix and it requires getting Jakub to spend time spinning all of gcc . no need to wait for entire gcc test suite to complete . can potentially push java-gcj-compat directly into libgcj SRPM . distro compiler changes independently of java class library => can lead to more bugfixes for the latter without potentially destabilizing the former
Cons: . skew between the two SRPMS? . no real upstream source for the libgcj SRPM's Source as it's derived from the gcc SRPM . will patches need to be maintained in multiple places? . will we be duplicating test suite running?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From fitzsim@redhat.com 2007-02-14 14:29 EST ------- I think this should happen so that we have faster turnaround time for pure-class library libgcj bugs. Jakub, do you think this is reasonable? As Andrew said, it doesn't seem reasonable to ask Jakub to do a multi-hour respin of the gcc rpms for the backport of a single patch from GNU Classpath.
That said, if this is going to happen for Fedora 7 I'm saying right now that we'll need an extension past the February 20th freeze. Jesse, is there a procedure for requesting such an extension?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From jkeating@redhat.com 2007-02-14 14:41 EST ------- Nothing official :/
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
fitzsim@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aph@redhat.com
------- Additional Comments From fitzsim@redhat.com 2007-02-14 17:05 EST ------- I talked this over with Jakub, Tom Tromey and Andrew Overholt, and we came up with an alternate proposal.
The main goal of splitting libgcj was to get class library fixes out to Fedora users faster. Jakub has explained to me that there are problems with that goal for Fedora updates: 1) we don't want to force users to download megabytes of updates very often (35M for a libgcj update (no debuginfo), 78M for a full gcc update (no debuginfo) and 2) we don't want to force re-prelinking more often than necessary (a libgcj update forces re-prelinking of all libraries linked to it (uses up to 10 minutes of CPU time according to Jakub).
He has suggested that we instead use updates-testing as a channel for fast delivery of libgcj updates to users. In this arrangement, the process for getting a class library fix out to Fedora users would be:
1) fix GNU Classpath upstream 2) backport the fix to redhat/gcc-4_1-branch in the GCC SVN repository 3) send mail to Jakub requesting a new gcc build in Fedora 7 updates-testing
Normal users would get the fix in the next gcc update, which would happen at a frequency of once every one or two months.
Users who want a fix immediately could do:
yum --enablerepo=updates-testing update libgcj
Jakub would be prepared to do these updates-testing gcc builds as long as they weren't needed more often than once per week.
The remaining concerns are:
1) Jakub is too busy on a given week to build a requested fix into updates-testing
Jakub, if this were the case, would it be possible for one of us from the Java group to do the build, after you've approved the proposed changes?
2) A class library bug that should be fixed for all libgcj users (not just those aware of/able-to-use updates-testing) is found early in the one-to-two month gcc update cycle
I don't have a good answer for this one. Those users will have to wait the one or two months for that update.
3) gcc will still have the same large set of BuildRequires
Does releng still consider this an issue?
4) The potential for merging java-1.5.0-gcj into libgcj
Jakub tells me he's open to accepting java-1.5.0-gcj constructs into the libgcj sub-rpm of the gcc spec file (alternatives, new SourceNs, etc.) so this merge can be done independent of the libgcj split.
Do people think this approach is acceptable/better than the split libgcj approach?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From dennis@ausil.us 2007-02-14 17:09 EST ------- in the new world we were not going to let packages linger in updates-testing for that long. I guess we could exclude glibc for longer time periods.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From fitzsim@redhat.com 2007-02-14 18:02 EST ------- (In reply to comment #11)
in the new world we were not going to let packages linger in updates-testing for that long. I guess we could exclude glibc for longer time periods.
What about gcc?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
------- Additional Comments From jakub@redhat.com 2007-02-15 10:41 EST ------- Wrt concerns: 1) yes, I guess it would be possible if we come up with some simple rules, e.g. such builds would be possible only if there weren't any changes checked in on the branch other than in libjava/ since the last gcc rpm built by myself and it used a release tag with dot inside (the former because things being checked there means a new gcc from me is in the works, the latter e.g. to not get out of sync e.g. with rawhide gcc) 3) even with separate libgcj the BuildRequires of gcc couldn't be trimmed down, as building untested gcj/jc1 is not an option - even with separate libgcj gcc build would need to build libgcj itself and run tests against it, only it wouldn't be installed by gcc subpackages.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
fitzsim@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |WONTFIX
------- Additional Comments From fitzsim@redhat.com 2007-02-15 20:39 EST ------- OK, I think that settles it. Though it would be nice to satisfy concern 2) as well, the simplicity of this compromise probably outweighs the downsides of a split libgcj. I'm closing this WONTFIX.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libgcj - separate libgcj srpm
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208613
bugzilla@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |medium Priority|normal |medium Product|Fedora Core |Fedora
tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|188265 | nThis| |
package-review@lists.fedoraproject.org