On Mon, Jun 09, 2003, Michael van Elst wrote: > > Log: > > no, proftpd certainly does not require getopt under runtime > > Whatever you say. But it is linked against libgetopt and without > the depdency it won't get rebuilt when libgetopt is updated.
I'm not sure whether I understand your correctly. Are you talking about a not triggered rebuild in openpkg-tool or about the fact that the package does break on a plain rebuilding? I guess you're talking about the first. And here I do not understand: in all of our applications, we never have a run-time dependency to libraries which were needed under build-time. The only exceptions are things like "ncurses" which is also a run-time beast for applications. But if an application like "proftpd" just links against libgetopt.a, it technically and from the RPM point of view correctly does not require the "getopt" package under run-time. Whether "proftpd" then should be nevertheless rebuiled if "getopt" is updated, is a pure openpkg-tool issue. Intuitively, it should be not rebuilded by default (because the installed "proftpd" no longer needs the installed "getopt"). But I would expect that openpkg-tool provides a "enforce rebuild paranoia" ;-) option which extends the run-time deps with the build-time deps to allow us to enforce the automatic rebuilding of "proftpd" here. Anyway, keep in mind that this is non-"proftpd" specific. All(!) of our application packages which have just build-time deps are affected by this behaviour of openpkg-tool AFAIK. So, optionally extending the rebuilding scope of openpkg-tool could be reasonable, couldn't it? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]