Request 156 was acted upon.
_________________________________________________________________________
URL: https://rt.openpkg.org/id/156
Ticket: [OpenPKG #156]
Subject: Correct package dependencies according to a single library policy
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: Nobody
Status: open
Transaction: Correspondence added by rse
Time: Wed Jun 11 13:21:28 2003
________________________________________________________________________
On Wed, Jun 11, 2003, Michael Schloh v. Bennewitz via RT wrote:
> [...]
> >>> In all of our applications, we never have a run-time dependency
> >>> to libraries which were needed under build-time.
> >>
> >> I beg to differ, we have many such dependencies. Dependencies to
> >> libraries are very often copied in BuildPreReq and PreReq.
> >
> >Then those packages are incorrect IMHO.
> >
> We definitely have two policies at OpenPKG.
>
> 1 Library dependencies are listed only as BuildPreReq
> 2 Library dependencies are listed as both BuildPreReq and PreReq
>
> Only one should be chosen, and all package dependencies accordingly adjusted.
I don't think we really had two _policies_, we just had different ways
of packaging ;-) And because of some prominent (and correct) exceptions
("ncurses", etc), people got confused and over time uses (2) from above
for all types of libraries.
I vote for:
1. plain library packages are technically just plain BuildPreReq deps.
2. exceptions are shared libraries (still not an issue) and library
packages which provide more than C headers and libs files and where
this additional stuff is needed by the linking application under
run-time. Those are both BuildPreReq (for the .h and .a files) and
PreReq (for the remaining stuff). Examples are "ncurses", etc.
3. we remove the currently existing (if any) PreReq deps to
library packages who are not of class in (2.).
4. we add a "enforce rebuild paranoia" ;-) option to openpkg-tool
to allow it to go from PreReq to BuildPreReq via Index in order to
also trigger an application rebuild if a library package is rebuild.
I perhaps also could accept (because of future shared library support):
1. all(!) library package deps become PreReq and BuildPreReq
2. we add the currently missing PreReq deps to library packages.
3. we leave openpkg-tool as is and let Michael v.E. be happy that he not
again has to tweak his little swiss-army-knife of OpenPKG packaging ;-)
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
