> It's not just somewhat exotic things such as dlopen > and embedded uses > of popen. It's in ordinary things such as scripts -- > some software > contains a great deal of scripting, and determining > correct > dependencies for those is both difficult and > error-prone because it's > a manual process.
Agreed. But IMHO you are still caught in/limited to SUN's "mixed" approach, which actually makes things complicated. If you would try the "source-package driven" approach you would probably be suprised at the small amount of deps you get. In case you'r just interested: a look at source RPMS of RH or build scripts of Gentoo would be sufficient to get a clue. Of course, one can close its eyes and say, we don't have the resources to determine the deps 100% and because we can't get the 100% we are doing it not at all. But IMHO, not in all cases 100% are necessary! E.g.: The LNFsamba-client contains only one script (findsmb). It uses perl . I categorize it as a supporting/contrib script, which is extremly rarely used by an end users. Also one might take into account, that perl5 is a kind of "core" component of the distrubution and a priori available. So I soften the 100% approach and just do not include P LNFperl5. Most people would not even notice the missing "pseudo" dep, since the remaining part of the package (which actually provides, what a usual user really needs) works without perl. Ananlog to this, you can handle supporting shell/python/$whatever scripts (no need to include deps for sh, grep, [n]awk, sed, tr, cut). And 2nd), not sure whether you got it right. If package C depends on package B and package B on package A, there is no need to include dep A in package C. pkgadd C would show you the dep to B, and pkgadd B would show the dep to A, so no problem at all. In case you might think pkgadd should resolve the deps to A when installing C as well: IMHO no - that's the task of a more sophisticated [un]install software... Last but not least, not always targetting the 100% goal may even improve user experience. A little story may explain it: Once a Ubuntu user asked me to help him to get its jboss running. Soon I found out, that a GNU Java (or was it blackdown - who cares ;-)) was installed on that system and recommended to remove those packages and install the real aka SUN jdk. He did that and since the OpenOffice had a dep to java, OpenOffice (and other packages, which do not really depend on java) was unconditionally removed as well. This user was really p.., that now he needed to download and install ~ 500 MB again... BTW: This is an example where a soften P flag (like O | S) might be really helpful. > And, as I mentioned before, there's really not much > point in doing > this as a single-shot event. If you can't maintain > it over time, then > all you've done is create an attractive nuisance -- > something that > looks like it contains correct dependencies, but in > fact is no more > reliable than the guesswork it replaced. The > dependencies will rot > over time. If you're going to do this at all, the > effort _must_ be > accompanied by the creation of tools and processes > that will keep the > information accurate. Yes - and the elfdump suggestion falls into this scope. One should see this as an "getting started tool" . An yes, as already said, if one really needs targets 100%, one has to have at least a look at the original source configure.ac as well as the scripts, which get installed. Since I use the original source packages, for most packages one can do a "rm -rf $PROTO; make DESTDIR=$PROTO" install and is able to do its analysis tool based/manually (and is even able to generate the prototype file pretty easy without forgetting something). And btw: since SUN builds compilers, I think SUN is even capable of buildiung a tool, which extracts dlopen calls even from stripped binaries ... > I think it's easy to throw rocks at the people who've > failed to give > you what you're asking for here. I also think it's > fairly difficult > to resolve the problem in a way that doesn't just > create new problems. Well, come out of your cage. Cut off the beard and try new things ;-) Many Linux distros, user requests, bug reports have proven, that SUN's currently used packaging policy is error prone, questionable, ancient, introduces _ a lot _ of homegrown problems and gives other software vendors as well as end users/admins a hard time. Also IMHO this ancient packaging policy is one of the main reasons, why SUN can't keep the pace with other modern *x distributions. And BTW: I also guess, that the time, required for (even manually) resolving dependencies is much less, that the time required for fixing bugs/problems and writing install software (which just can't work) introduced dueto the "mixed" packages [and missing deps]. So finally, yes, SUN may close its eyes and say "we are doing it different because we are SUN", we do not need to learn from others, but that's your business and falling behind as well... Regards, jens. This message posted from opensolaris.org
