1 |
On Thursday 21 September 2006 10:38, Alin Nastac wrote: |
2 |
> Brian Harring wrote: |
3 |
> > There is one flaw with this though; packages can provide both |
4 |
> > libraries _and_ binaries. Our dependencies don't represent whether |
5 |
> > the dep is actual linkage, or just commandline consuming, so (using |
6 |
> > the openssl example) any package that invokes openssl via the |
7 |
> > commandline to do a few simple chksum ops gets rebuilt, despite the |
8 |
> > fact it wasn't affected by linkage change ups. |
9 |
> |
10 |
> I like BINCOMPAT proposal but it solves only half of the problem. You |
11 |
> assume that all dependent packages cares about binary compatibility. |
12 |
> Why not using a BDEPEND var in those dependent packages affected by the |
13 |
> BINCOMPAT values of their dependencies? |
14 |
> |
15 |
> For instance, I would set the following: |
16 |
> - in net-dialup/ppp ebuild: BINCOMPAT=${PV} |
17 |
> - in net-dialup/pptpd ebuild: BDEPEND="net-dialup/ppp" |
18 |
|
19 |
i think you're merging the two issues you brought up ... there is binary ABI |
20 |
issues (which should not require a new DEPEND variable as portage can extract |
21 |
that information out at runtime) and there is runtime plugin issues with |
22 |
packages using dlopen() (which portage cannot extract as the dependency |
23 |
cannot ever be extracted) |
24 |
|
25 |
or did i not read your original e-mail incorrectly ? |
26 |
-mike |