| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Friday 04 June 2004 08:49, Andrew Gaffney wrote: |
| 5 |
> Jason Stubbs wrote: |
| 6 |
> > On Friday 04 June 2004 03:53, foser wrote: |
| 7 |
> >>>On Thu, 2004-06-03 at 19:41 +0200, Marius Mauch wrote: |
| 8 |
> >>>>On 06/03/04 Aron Griffis wrote: |
| 9 |
> >>>>>I'm under the impression that this is bad. Could somebody please |
| 10 |
> >>>>>verify and explain for the sake of people on this list. This |
| 11 |
> >>>>>particular example appears in the libxslt ebuilds, but the kde ebuilds |
| 12 |
> >>>>>make use of a similar syntax: |
| 13 |
> >>>>> |
| 14 |
> >>>>> use python && inherit python |
| 15 |
> >>>> |
| 16 |
> >>>>Bad because it breaks the cache. Depending on the status of the python |
| 17 |
> >>>>flag *on the rsync master* the cache settings are or are not modified |
| 18 |
> >>>> by the python.eclass and could be completely different from the values |
| 19 |
> >>>> the cache should have for the user. That's also the case for other |
| 20 |
> >>>> cache variables like DEPEND, SRC_URI or SLOT, if you make them |
| 21 |
> >>>> conditional on the environment it's likely that the cache values are |
| 22 |
> >>>> wrong for some people. |
| 23 |
> >>> |
| 24 |
> >>>The problem is that it shouldn't be a problem to do things like this, |
| 25 |
> >>>it's portage that makes it problematic. It is not obvious why this is |
| 26 |
> >>>problematic, so situations like these are going to pop up time and time |
| 27 |
> >>>again. In my opinion this need to be fixed in portage, not necessarily |
| 28 |
> >>>in the ebuilds/eclasses. And yeah, i'm talking here without any |
| 29 |
> >>>knowledge of portage cache handling, ideal world type of talk. |
| 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 |
| 35 |
> > syntax. 3) Make everything constant in the global section of ebuilds. |
| 36 |
> > |
| 37 |
> > #1 is definately not acceptable at this stage as dep calculation time |
| 38 |
> > would take about 50 times as long. #2 is probably the best but offers no |
| 39 |
> > short term solution. Which leaves #3. |
| 40 |
> |
| 41 |
> In the Perl Portage clone I was working on, I originally didn't use caching |
| 42 |
> and it could generate a (mostly) correct deptree for xfree faster than |
| 43 |
> Portage could. Adding support for Portage's cache only shaved off about .2 |
| 44 |
> seconds. |
| 45 |
|
| 46 |
That's worth investigating then. Perhaps the bulk of the time when doing deps |
| 47 |
without a cache is the actual creation of the cache... It doesn't sit right |
| 48 |
with me, though. I'll look into it further. |
| 49 |
|
| 50 |
Regards, |
| 51 |
Jason Stubbs |
| 52 |
-----BEGIN PGP SIGNATURE----- |
| 53 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 54 |
|
| 55 |
iQCVAwUBQL+8uloikN4/5jfsAQI94wP/f8lKzg5vu6fyezHhgC8sfldBg+XRxv3e |
| 56 |
yKxYUiOT/pber0vrnAux4wlH0nl0X5p1oGT48GEMLuyvWsHOf9j8+/yplgt/BhVd |
| 57 |
xCSuCliON3Z0GCD+9+8D9fanJa2gvk87aq2lgvaQLtdZy1BLb5BgpyBILyu4vWkS |
| 58 |
1LaDDI88LhY= |
| 59 |
=C5+W |
| 60 |
-----END PGP SIGNATURE----- |
| 61 |
|
| 62 |
-- |
| 63 |
gentoo-dev@g.o mailing list |
Archives