Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays?
Date: Sat, 23 Apr 2011 11:17:07
Message-Id: 4DB2B4EC.3070901@gentoo.org
In Reply to: [gentoo-dev] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays? by "Chí-Thanh Christopher Nguyễn"
1 On 04/23/2011 03:28 AM, Chí-Thanh Christopher Nguyễn wrote:
2 > Eray Aslan schrieb:
3 >> https://bugs.gentoo.org/show_bug.cgi?id=364445
4 >> https://bugs.gentoo.org/show_bug.cgi?id=364401
5 >>
6 >> Basically, there are requests to add packages to RDEPEND in virtual/mda
7 >> and virtual/mta that are not in the official tree but in sunrise.
8 >>
9 >> On one side, *DEPENDing on a package outside the tree doesn't seem
10 >> right.
11 >
12 > I understand that the push to remove old-style virtuals from the main
13 > tree is because they cause headaches for the package managers during
14 > dependency calculation. I also understand that existing EAPIs will not
15 > be amended to forbid old-style virtuals.
16 >
17 > Would it make sense to do the following:
18 > (1) make all new-style virtuals additionally depend on an old-style
19 > virtual (a new category might be appropriate)
20 > (2) ebuilds in overlays can PROVIDE the old-style virtual
21
22 It seems like new-style virtual would be introducing complexity without
23 adding any value here. Why not just use a pure old-style virtual?
24
25 > (3) in a future EAPI, package managers are allowed to ignore the
26 > old-style virtual dependency for packages which are not already installed
27
28 I'm not sure what you mean here. In || dependencies, it's normal to
29 ignore choices that are masked or unavailable, so I'm not sure that
30 you're suggesting anything different from the existing || behavior.
31
32 > If directly including installed old-style virtual packages in the
33 > dependency calculations is not feasible, (3) could be implemented
34 > through modifying package.provided like it is already done for
35 > package.{keywords,mask,use} after profile/ updates
36
37 Again, I'm not sure that I understand the point of this. Since ||
38 dependencies already ignore unavailable or masked choices, why would
39 package.provided be needed?
40 --
41 Thanks,
42 Zac

Replies