Actually, what I'm trying to do is the following, may be you have an
advice for me:
I'm running RHEL-5, I found it the most stable and secure Distro that runs
smoothly almost all the high-end simulation and 3D applications that I'm
using intensively, the problem is that there are dozens of simple but
important applications/utilities that requires higher versions of glibc
and python, those that where supplied as rpm packages that requires newer
versions of the RPM to be installed!
So, I decided to build a custom system installation that satisfies all my
needs.
I manually forced upgrade glibc with a version that gives 2.6 and 2.7
without breaking the system dependencies, and I compiled python-2.7.2, and
now my system runs really great! and I can run those new applications
smoothly.
The only one thing that I'm suffering from is that I have to manually
extract and install them since they require higher signature of
fileDegist, payload and rpm compressing... for that I decided to upgrade
to RPM-5 to be able to install them regularly using the RPM Packager.
Any advices about that! are there an easy way to let the RPM source
compile both of the i686 and x86_64 bit.
What I'm confused about, is that the RPM has many dependencies, and I
don't know which one of them should be compiled for both i686 and x86_64
and which needs to only compile for x86_64.
Regards,
Belal
On Mon, 08 Aug 2011 20:51:52 +0300, Jeff Johnson <n3...@mac.com> wrote:
On Aug 8, 2011, at 12:39 PM, Belal Salem wrote:
Yes!
The repository you give to me is a good place to compare the versions I
have and to upgrade what needs upgrading.
Thanks for your time.
NP. If you catch some annoyance, its not personal:
I maintain both RPM5 and POPT and yours isn't the first
report of build failures.
The problem isn't simple: RPM uses POPT in easy that no other program
does.
E.g. POPT_ARGFLAG_TOGGLE adds the ability to set/clear a set of flags
from
CLI options with both
--thisoption
--nothisoption
Since RPM is chock full of disablers (like --nodeps etc) which are
attempting
to use POPT_ARGFLAG_TOGGLE in reasonable ways, well, the inability to
upgrade
POPT by distros in 3-4 years is, well, a tad bit disturbing.
POPT is *NOT* a hard upgrade, nowhere near as complicated as upgrading
RPM has become.
Anyways holler at me (and ignore my mutterings) if you need help. I'll
try
to get you fixed up no matter what …
(aside to Robert Xu):
Getting there just buried …
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
