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