1 |
On Thu, Sep 21, 2006 at 05:38:08PM +0300, Alin Nastac wrote: |
2 |
> Brian Harring wrote: |
3 |
> > On Thu, Sep 21, 2006 at 01:38:59PM +0200, Luca Barbato wrote: |
4 |
> > |
5 |
> > There is one flaw with this though; packages can provide both |
6 |
> > libraries _and_ binaries. Our dependencies don't represent whether |
7 |
> > the dep is actual linkage, or just commandline consuming, so (using |
8 |
> > the openssl example) any package that invokes openssl via the |
9 |
> > commandline to do a few simple chksum ops gets rebuilt, despite the |
10 |
> > fact it wasn't affected by linkage change ups. |
11 |
> > |
12 |
> I like BINCOMPAT proposal but it solves only half of the problem. You |
13 |
> assume that all dependent packages cares about binary compatibility. |
14 |
> Why not using a BDEPEND var in those dependent packages affected by the |
15 |
> BINCOMPAT values of their dependencies? |
16 |
> |
17 |
> For instance, I would set the following: |
18 |
> - in net-dialup/ppp ebuild: BINCOMPAT=${PV} |
19 |
> - in net-dialup/pptpd ebuild: BDEPEND="net-dialup/ppp" |
20 |
|
21 |
BDEPEND was actually a seperate proposal/idea, intention there was to |
22 |
have that be the deps that *must* be CHOST (gcc would be an example); |
23 |
bits that are used to actually build the pkg, not data it consumes in |
24 |
building (headers would be data). |
25 |
|
26 |
Meanwhile, for this I don't see the point in using a seperate metadata |
27 |
key. Overload DEPEND and add a marker char that is used to indicate |
28 |
that a particular dependency is 'binding', ie, it is linkage. |
29 |
|
30 |
~harring |