On 2/23/2011 9:34 AM, Ljubomir Ljubojevic wrote:
>
> 2. 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.
> 6. 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.
--
Les Mikesell
lesmikesell at gmail.com