On Aug 8, 2011, at 1:19 PM, Belal Salem wrote:
> 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!
Yes, you aren't alone here either: most "enterprise" distros have such a ;one
"supported" life that they become irrelevant.
I'm not sure that ether's any "enterprise" distro with a solid upgrade path.
Dag's repository is likeliest best both reputation ally and in in "reality".
Check there first imho.
> 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.
Upgrading REHL5 to python-2.7.2 is non-trivial: congratulations on success.
> 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.
Yes: distros have chosen to use SHA-256 file digests without bothering
to release a compatible version of rpm.
There is a way to disable file digests using --nofdigests (I've forgotten the
older option, it has been 6 years or so: --nomd5sums? something like that).
Sadly that *still* isn't enough because of the XZ! XZ! XZ! craziness. So there's
often nothing one can do except extract the payload
rpm2cpio.sh foo*.rpm | cpio -dim
(there's a shell script that permits inserting a unxz where needed).
There are back ports of XZ and SHA256 file digests to whatever RPM is
in RHEL5 if needed: I can dig out the necessary patches if GOOG
cannot find something that Just Works.
> Any advices about that! are there an easy way to let the RPM source compile both of the i686 and x86_64 bit.
All depends on what is considered "easy".
FYI: rpm-4.4.7 (on which @rpm5.org is based) treats arch simply as a string. SO
it's entirely feasible to do
rpmbuild -ba --target=hotmommacpu foo.spec
and end up producing binary
Whether that is useful or not is a far more complex answer: but RPM won't stop you
For RHEL5, its likely easiest to add (and change)
which contains in 1-line the usual config.guess string like
There are ways to invoke with a setarch(1) prefix like
setarch x86_64 rpmbuild -ba yadda.spec
but I find that rather more annoying than easy: usually I'm building
a set of packages, and editing /etc/rpm/platform is persistent (and easy)
even if I usually forget to check the setting when building.
> 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.
All ELF dependencies have a "color" and are attached to file(s) (if the functionality is not disabled).
So color is 0 == "white", 1 == elf32, and 2 == elf64 and you can see the dependencies by doing
rpm -qp --filerequire *.rpm
to see which dependencies are associated with each file.
There is a --fileprovide as well, and you can also see what rpm is going'
to do by typing, say,
find /bin | /usr/lib/rpm/rpmdeps --requires
echo "/bin/sh" | …
(there's a --provides analogue to --requires too).
Other arch-specific dependencies are usually dictated by Packaging Policy Police somewhere.
Note that RHEL5 is particularly strangely painful in the way it handles ix86 <-> x86_64 "multilib".
73 de Jeff
Received on Mon Aug 8 21:37:13 2011