Re: Over 40% of the 6.0 RPM's, especially SRPM's, are not RHEL 5 compatible

Nico Kadel-Garcia <[email protected]>
Newsgroups gmane.linux.jpackage.general
Message-ID <[email protected]>
On Tue, Apr 27, 2010 at 1:11 PM, Will Tatam <[email protected]> wrote:
> On 02/04/10 18:31, David Walluck wrote:
>> On 04/02/2010 08:50 AM, Nico Kadel-Garcia wrote:
>>
>>> Great. I'd be happy with the SRPM's for now: building the RPM's under
>>> RHEL 5 is..... an adventure, due to the age of the Java components
>>> under RHEL.
>>>
>> I've been having some problems with the JPackage server lately.
>> Ultimately, we can script the rebuild process.
>>
>> Some people prefer that our host OS be CentOS, so that's probably how it
>> will stay, although I think Fedora with the right defines will also work.
>>
>>
> I have already run a script that tried to rebuild everything, though it
> failed for many packages due to the order in which the package need to
> be complied and many of them I think will need to re-bootstrapping to
> rebuild without needing any of the JPP 6 packages that have not been rebuilt

Yeah, it's bloody painful. There's also the
/usr/bin/rebuild-security-providers dependency, which is provided in
the jpackage-utils-compat-el5 widget I've provided previously. But the
SRPM's could be extracted via various means and repackaged without
those issues: it creates a bit of uncertainty about the SRPM
provenance, especially if some smart-aleck has wrapped '%ifdef''
around 'Source' or 'Patch' statements. Fortunately, I've not noticed
anyone pulling that stunt for JPackage, so it should be OK to simply
rewrap and update the release numbers of the SRPM's, even if they're
only listed in an RHEL 5 specific subrepository.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.