[Attempting to post onto Cc:d lists that bounced my reply.] Mark Burgess <[EMAIL PROTECTED]> writes:
>> >> The real pain is the that cfengine requires a non-system version of db >> (and libcrypto?) which need to be linked statically because `cfexecd >> -L' isn't useful, since cfexecd links them itself. You either risk >> distributing binaries which won't load and break the client, or you're >> statically linked against an openssl library that may get a security >> alert. > > I have no idea what this means. That's worrying. > Cfengine certainly does not require a "non-system" version of db or > lib crypto. That's the first thing INSTALL says, though obviously it's wrong that you must install the latest versions. It is an experimental fact that the current Cfengine will not configure against the Berkeley db and OpenSSL in /usr on a Solaris 10 system which was fully updated within the last fortnight, any more than it will on other versions of Solaris, Irix &c. [It _may_ be that cfengine _could_ use them on Solaris 10 with autoconf changes but obviously there's no point in checking.] > They do not need to be statically linked. No, as I said above, but experience of actually maintaining a network of Solaris (amongst other) boxes shows that if you don't statically link them, you probably end up with broken installations when the clients miss the dynamic libraries for one reason or another. Some admins may be perfect and won't have such trouble, and mileage always varies. > What kind of nonsense is this? > > Apologies for this misinformation. > > Cfexecd -L has nothing to do with static linking, it is for working > around broken ldso.conf ld.config on Solaris, perhaps, but that's not broken on my systems, and if I wanted to create one, I have an equivalent maintenance issue. Even if the doc is wrong about -L (though it agrees with the code), it simply isn't likely to be useful; if it's necessary then cfexecd probably won't load as ldd shows. For what it's worth, if I remember correctly that's a regression which I may even have failed to report via the useless bug address. I've come to the conclusion that cfengine maintenance makes it something one doesn't really want to rely on in the sort of situation I've been in where it's actually supposed to win. This sort of response confirms that, unfortunately. _______________________________________________ Bug-cfengine mailing list Bug-cfengine@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cfengine
