[CentOS-devel] progress?

Wed Feb 23 16:11:57 UTC 2011
Les Mikesell <lesmikesell at gmail.com>

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