1 |
Jason Stubbs wrote: |
2 |
> On Friday 04 June 2004 03:53, foser wrote: |
3 |
> |
4 |
>>>On Thu, 2004-06-03 at 19:41 +0200, Marius Mauch wrote: |
5 |
>>> |
6 |
>>>>On 06/03/04 Aron Griffis wrote: |
7 |
>>>> |
8 |
>>>>>I'm under the impression that this is bad. Could somebody please |
9 |
>>>>>verify and explain for the sake of people on this list. This |
10 |
>>>>>particular example appears in the libxslt ebuilds, but the kde ebuilds |
11 |
>>>>>make use of a similar syntax: |
12 |
>>>>> |
13 |
>>>>> use python && inherit python |
14 |
>>>> |
15 |
>>>>Bad because it breaks the cache. Depending on the status of the python |
16 |
>>>>flag *on the rsync master* the cache settings are or are not modified by |
17 |
>>>>the python.eclass and could be completely different from the values the |
18 |
>>>>cache should have for the user. That's also the case for other cache |
19 |
>>>>variables like DEPEND, SRC_URI or SLOT, if you make them conditional on |
20 |
>>>>the environment it's likely that the cache values are wrong for some |
21 |
>>>>people. |
22 |
>>> |
23 |
>>>The problem is that it shouldn't be a problem to do things like this, |
24 |
>>>it's portage that makes it problematic. It is not obvious why this is |
25 |
>>>problematic, so situations like these are going to pop up time and time |
26 |
>>>again. In my opinion this need to be fixed in portage, not necessarily |
27 |
>>>in the ebuilds/eclasses. And yeah, i'm talking here without any |
28 |
>>>knowledge of portage cache handling, ideal world type of talk. |
29 |
> |
30 |
> |
31 |
> Three options: |
32 |
> |
33 |
> 1) Drop portage caching altogether. |
34 |
> 2) Separate the global section into a separate non-bash file with new syntax. |
35 |
> 3) Make everything constant in the global section of ebuilds. |
36 |
> |
37 |
> #1 is definately not acceptable at this stage as dep calculation time would |
38 |
> take about 50 times as long. #2 is probably the best but offers no short term |
39 |
> solution. Which leaves #3. |
40 |
|
41 |
In the Perl Portage clone I was working on, I originally didn't use caching and |
42 |
it could generate a (mostly) correct deptree for xfree faster than Portage |
43 |
could. Adding support for Portage's cache only shaved off about .2 seconds. |
44 |
|
45 |
-- |
46 |
Andrew Gaffney |
47 |
Network Administrator |
48 |
Skyline Aeronautics, LLC. |
49 |
636-357-1548 |
50 |
|
51 |
|
52 |
-- |
53 |
gentoo-dev@g.o mailing list |