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]
