On 2/23/2011 9:34 AM, Ljubomir Ljubojevic wrote:
- When you deal with hidden dependencies, what comes to my mind is to
first see dependencies from Fedora12(+) packages by *manually* extracting and comparing .spec files one SRPMS at the time (everybody from team was assigned part of the non-building SRPMS).
Aren't there some tools that are designed to find binary similarities (think anti-virus or things that try to detect copied code sections)? ldd should tell you about any dynamically-linked libraries needed, but there should be a way to fingerprint the likely suspect libraries and identify static libs that are linked - at least to the extent you could identify a code virus in a binary.
- Built RPMS from item 5 are then compared to the RHEL original.
Can't whatever they are comparing here be used directly in some clever test to predict what would be needed instead of a trial and error approach?
As you can see, there is no much automation going on except for few initial runs, just hard manual labor and frustration.
What happens with script-language packages that do their own equivalent of dynamic linking at runtime?
I have tried to compile many packages for CentOS 5.x that depend on much newer core files, and finding out what packages I also need to recompile from Fedora was highly frustrating, and I was just using known dependencies from existing .spec files.
Certain packages (especially their newer versions) would have as much as 15-20 dependencies (6-7 layers of dependencies deep) until I would hit some core package I was unwilling to change. And then I would start with older package version hopping that they do nor require those core packages.
It would take me even 10-12 hours (until I learn how to cut it shorter), for a single package.
Even if no one can come up with a way to extrapolate the dependencies from the RHEL binary, the task seems like something that would scale with more build machines and more people to stage the trial-and-error builds. And if those people aren't part of the trusted few, they could send back the info needed to duplicate the build. But, I suppose you'd need to export hash fingerprints or something similar to test against for people who don't have access to the official RHEL binaries.