John Morris
2004-05-17 23:12:38 UTC
Time to toss one out to the list and get an opinion.
The problem: the version of rpm included in U2 can't be patched for
whitebox. The patch touches configure.ac and this triggers off GNU
autoconf/automake/libtool/blah/blah when the package gets rebuilt.
Problem is this new version of rpm depends on a much newer version of all
that GNU auto[blah] than they supply for RHEL3.
Options I have thought of:
1. Ignore this update to rpm. Not really an option because it adds ia32e
as an arch and that will be needed for the x86_64 port. Plus there are a
lot of bug fixes listed in the changelog.
2. Stuff the package on a Fedora machine, merge the patch, run autoconf
and repackage. This should allow rebuilding on WBEL so long as no changes
get reintroduced which would trigger autoconf. This option totally breaks
the pristine source+patch concept since it would mean repacking the
tarball.
3. Bring in the newer autoconf/automake/etc and include them in lostRPMS.
4. Wade in and back out the changes which require newer tools. This
would involve major surgery on a core piece of software. Not preferred.
Longterm I believe I should contact the rpm maintainers and see about
getting my two line patch incorporated upstream so this won't be a problem
in the future, because I don't see RH considering our problem as their
problem since an unmodified package builds correctly.
The problem: the version of rpm included in U2 can't be patched for
whitebox. The patch touches configure.ac and this triggers off GNU
autoconf/automake/libtool/blah/blah when the package gets rebuilt.
Problem is this new version of rpm depends on a much newer version of all
that GNU auto[blah] than they supply for RHEL3.
Options I have thought of:
1. Ignore this update to rpm. Not really an option because it adds ia32e
as an arch and that will be needed for the x86_64 port. Plus there are a
lot of bug fixes listed in the changelog.
2. Stuff the package on a Fedora machine, merge the patch, run autoconf
and repackage. This should allow rebuilding on WBEL so long as no changes
get reintroduced which would trigger autoconf. This option totally breaks
the pristine source+patch concept since it would mean repacking the
tarball.
3. Bring in the newer autoconf/automake/etc and include them in lostRPMS.
4. Wade in and back out the changes which require newer tools. This
would involve major surgery on a core piece of software. Not preferred.
Longterm I believe I should contact the rpm maintainers and see about
getting my two line patch incorporated upstream so this won't be a problem
in the future, because I don't see RH considering our problem as their
problem since an unmodified package builds correctly.
--
John M. http://www.beau.org/~jmorris This post is 100% M$ Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r
John M. http://www.beau.org/~jmorris This post is 100% M$ Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r