Re: What should go in JPP6, and what as update to JPP5? When is support for RHEL versions dropped?

On Sat, Jan 9, 2010 at 9:43 AM, Will Tatam <[email protected]> wrote:
> Nico Kadel-Garcia wrote:
>>
>> In the short term, I've published some hooks for this on this mailing
>> list. The summary of the RHEL 5 compatibility issues of JPP5 is below:
>>
>
> After a bit of experimentation, I'm part way though downgrading the
> buildroot for jpp6 to use centos5, but as discussed this requires all
> packages built prior to this change to be rebuilt.
> I wrote something to rebuild all the jpp5 packages in mock when we swapped
> to using a mock buildroot, so I should be able to do something similar for
> this jpp6 rebuild
>>
>> * JPackage often uses ".noarch" packages rather than .i386/x86_64.
>> This causes serious confusion when there is an old .i386 version in
>> RHEL 5, a new noarch one from JPackagae, and yum tries to grab and
>> install the .i386 version as well as the .noarch from JPackage. The
>> easy solution is to put entries like these ' in your yum.conf.
>>
>>       exclude=ant.i386
>>       exclude=tomcat5.i386
>>
>> Hmm. This list would be good to publish.
>>
>
> I personally have not had any issue since I installed the jpackage-release
> package that provides a yum config with the right priority stuff in there.
> Let me know if you are still having issues with packages.

I bet you're using CentOS, not RHEL? RedHat's yum setup is basically
up2date in grandma's clothing. It has no yum config file in which to
insert repository specific priorities or exclusions, which is really
flipping irritating. This, in fact, is why I rip out yum-rhn-plugin on
most machines, set up a local "reposync" built repository of RHEL
software, and apply local yum .repo files to access it.

It's also *MUCH FASTER* than grabbing things from a remote RHEL repo,
especially for mock.

>> * RHEL 5 obsoleted the 'ecj' package with 'eclipse-ecj'. This causes
>> nuttiness, unless you provide an eclipse-ecj of a higher version
>> number to displace the RHEL 5 one and eliminate the 'Obsoletes': that
>> will allow the installation of JPackage ecj, and satisfy eclipse-ecj
>> dependencies. I'm happy to send you a copy of my placeholder .spec
>> file for this
>>
>
> Send me the src.rpm and I'll import into CVS and make you the package
> maintainer. Have you been given a CVS account yet ?

Cool, it's attached, it's just a .spec file.

No, I don't yet have CVS account. I can work with CVS: it actually
makes me twitch for security reasons: is there any plan to migrate to
"git", or something with better security models?

>> * The java-1.6.0-sun and java-1.6.0-sun-compat packages are seriously
>> out of date. Again, I'm happy to send you the copies of my .spec
>> files.
>>
>> In fact, I'd be willing to maintain those now.
>>
>
> Once you have a CVS account, we can let you keep that upto date. Publishing
> the nosrc.rpm packages are a bit of a pain as they aren't real packages so
> need to be dealt with differently and are not part of our automated upload
> system currently

Right. I'm having a confusing issue with .nosrc.rpm's where doing
"rpmbuild -bs package.spec" refuses to build without the Source
available, and includes the cotton picking NoSource: labeled
component. I'm not sure why I'm seeing this.