1 |
On Wednesday 23 November 2005 00:46, Donnie Berkholz wrote: |
2 |
> Doug Goldstein wrote: |
3 |
> > I thought GLEP 37 was a way out kind of thing. Like several months if |
4 |
> > not a year before it can be done. |
5 |
> |
6 |
> I figured about the same, but |
7 |
> https://bugs.gentoo.org/show_bug.cgi?id=112896#c16 begs to differ. |
8 |
|
9 |
The glep was originally posted 30th April... |
10 |
|
11 |
The idea was already fairly solid at that time and required minimal changes to |
12 |
portage for it to "just work". Pretty much only one actually - the hardcoded |
13 |
'sanity check' of not being able to install packages of category "virtual" |
14 |
was removed. Hence, as per the backwards compatibility section of the glep, |
15 |
all current portages are capable of handling virtuals that are regular |
16 |
packages. The largest holdup was waiting for backwards compatibility to |
17 |
become viable. |
18 |
|
19 |
There are really only two other parts to the glep; consistency checking and |
20 |
user overrides. The current method of overriding will still work fine and |
21 |
only becomes an issue when the first virtual that covers a set of packages |
22 |
comes into existence. As for consistency checking, it has a relatively small |
23 |
chance of being useful in my opinion. Take the following: |
24 |
|
25 |
# emerge virtual/x11 |
26 |
# emerge -C x11-base/xorg-x11 |
27 |
# emerge x11-libs/qt |
28 |
(Whoops!) |
29 |
|
30 |
In other words, it's a situtation that is possible already. The solution is to |
31 |
always use --deep when calculating dependencies, which I'm working on at the |
32 |
moment. There are a couple of other portage-side implementation issues that |
33 |
have come up, but the more difficult ones have become clearer over time. I'll |
34 |
dust of the GLEP and repost it later this week and see if we can't get it |
35 |
finalized... |
36 |
|
37 |
-- |
38 |
Jason Stubbs |
39 |
-- |
40 |
gentoo-dev@g.o mailing list |