[Bug 208613] Review Request: libgcj - separate libgcj srpm

[bugzilla at redhat.com]

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 at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at redhat.com




------- Additional Comments From fitzsim at 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?


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.