1 |
On Thu, Sep 21, 2006 at 08:15:48PM +0300, Alin Nastac wrote: |
2 |
> Brian Harring wrote: |
3 |
> > BDEPEND was actually a seperate proposal/idea, intention there was to |
4 |
> > have that be the deps that *must* be CHOST (gcc would be an example); |
5 |
> > bits that are used to actually build the pkg, not data it consumes in |
6 |
> > building (headers would be data). |
7 |
> > |
8 |
> Well, until now I didn't thought at the build compatibility. |
9 |
> My concern was only the runtime compatibility. |
10 |
> > Meanwhile, for this I don't see the point in using a seperate metadata |
11 |
> > key. Overload DEPEND and add a marker char that is used to indicate |
12 |
> > that a particular dependency is 'binding', ie, it is linkage. |
13 |
> > |
14 |
> Lets suppose we use & as 'binding' dependency marker. What sense would |
15 |
> DEPEND="&net-dialup/ppp" have in a context of an ebuild. It certainly |
16 |
> don't specify the necessity of package rebuild whenever net-dialup/ppp |
17 |
> version is changed. |
18 |
> |
19 |
> Unless you save the specific compatibility version of the net-dialup/ppp |
20 |
> used by net-dialup/pptpd for building the package, I don't see how can |
21 |
> it help me. |
22 |
> Judging after /var/db/pkg content, I have no such information. |
23 |
|
24 |
Any such implementation would require storing some extra data in the |
25 |
vdb.... |
26 |
|
27 |
For this, would just walk the *DEPEND collecting 'binding' |
28 |
dependencies, and storing their BINCOMPAT in a simple mapping. |
29 |
|
30 |
~harring |