On 2003-06-05(Thu) 09:17:13 +0200, Götz Waschk wrote:
Am Donnerstag, 5. Juni 2003, 03:58:38 Uhr MET, schrieb R.I.P. Deaddog:
On 2003-06-03(Tue) 10:58:42 +0200, Götz Waschk wrote:
it would be nice if the find_requires script would parse the
dependancies of static libraries, but how to do this? It's easy to
find out the dependant libs of shared libraries, but AFAIK shared
libraries only contain information about which symbols are unresolved,
but no information on where to get that symbols. Has anyone thought
Yes, I discussed with Stefan about static lib dependency too, and don't have any conclusion about it. Here are the possible difficulties:
For any missing symbol in one static lib, we can possibly find more than one matches in other static libs. Besides, searching through ALL static libs in one machine to find matches is very time consuming, and (unconfirmed) possibly give different results in different machines.
This is not unsolvable, for example, by recording all missing symbols of static libs somewhere, and grep the lists of symbols instead.
I have a conjecture: dependency of static libs must be a subset of dependency of dynamic libs. Will it be simpler if my guess is true?
I remember the discussion. I guess solving this one is going to be less trivial than the .so one.
Let's ramble a bit... brainstorm if you will.
Let's at the numbers: 44 *static* packages 386 *devel* packages (excluding *static*)
It would be perfect if a -static-devel packages would Require it's -devel counterpart (dependency from the .spec file) and get the rest of the info from the files in the package, like the way the current -devel dependencies work. Is this assumption correct?
But how?
do the same as with the .so dependencies, but then add a Provides: .a" and "Requires: .a" dependencies?
With the numbers as they are above, quite some -devel packages will need to be split up into -static-devel packages, or the ".a" dependencies will just be added to the -devel packages. Why not move the static-devel packages back into the -devel packages?
The way things are at the moment (concering .so dependencies):
- quite some packages need to be rebuilt for the new dependencies. This is ongoing and progresssing.
- quite some packages containing plugins (gnomegames comes to mind) need to be fixed --> .so's need to be built with -avoid-version?? Of course fixes need to be communicated back to the original projects;
- quite some packages need to move their devel files to the -devel package. rpmlint doesn't detect all of them as it only looks in "/usr/lib" and not any deeper (true or false??);
- I'd like to see a comprehensive rpm package dependency (and / or naming) standard be made which is distribution independant. Using dependency information based on capabilities is a step forward. This way we can become less dependany on the actual name a package has. I've proposed the .so stuff in redhat's rpm-list, no response from any rpm developers there. If this doesn't get pushed beyond mdk, it's only going to make the "rpm hell" worse, while it _could_ help solve it;
- the find-provides and find-requires in rpm-4.2-7mdk need to be updated to the latest version. The one in -7mdk doesn't pick up the dependencies in the rpm-devel package. Luckily no -devel package I know of Requires rpm-devel, which makes it less urgent.
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
