1 |
On Tue, 18 Sep 2012 20:44:33 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Tue, 18 Sep 2012 12:40:51 -0700 |
5 |
> Zac Medico <zmedico@g.o> wrote: |
6 |
> > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote: |
7 |
> > > On Tue, 18 Sep 2012 12:25:57 -0700 |
8 |
> > > Zac Medico <zmedico@g.o> wrote: |
9 |
> > >> Also, if we change the meaning of RDEPEND in the next EAPI, so |
10 |
> > >> that it's a hard build-time dep like DEPEND, then |
11 |
> > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to |
12 |
> > >> DEPEND="virtual/pkgconfig". This is what I would like to do for |
13 |
> > >> the experimental EAPI 5-hdepend which is planned [1]. |
14 |
> > > |
15 |
> > > What're we going to do about the zillions of unsolvable cycles |
16 |
> > > that that would create? (Does Portage detect those and error out |
17 |
> > > yet?) |
18 |
> > |
19 |
> > Yeah, it would be treated just like a DEPEND cycle, which is already |
20 |
> > detected and treated as a fatal error. As a result, when bumping the |
21 |
> > EAPI of an ebuild, you may have to migrate some deps from RDEPEND to |
22 |
> > PDEPEND in order to solve the cycles. |
23 |
> |
24 |
> What about the large number of RDEPENDs that are required for a |
25 |
> package to be usable, but not for it to be installed? |
26 |
|
27 |
They will still be RDEPEND, just installed earlier I believe. Except |
28 |
for those arising conflicts which will have to be moved to PDEP. But |
29 |
I think Zac said that already. |
30 |
|
31 |
-- |
32 |
Best regards, |
33 |
Michał Górny |