1 |
On Sat, 2004-10-09 at 02:45, Dan Armak wrote: |
2 |
> On Friday 08 October 2004 22:08, Brian Harring wrote: |
3 |
> > Well... that's weird, attempted to send this directly to dan, having it |
4 |
> > bail due to |
5 |
> > 'failed: relaying not allowed: danarmak@g.o' |
6 |
> > I assume I'm being an idiot and screwing up the address (or local |
7 |
> > configuration)... |
8 |
> All I can say is, I can receive at that address quite well... |
9 |
Don't worry about it, I was being an idiot (usually a valid assumption). |
10 |
|
11 |
> I did, but it's tied to your ability to call back into python from ebuild.sh, |
12 |
> so I couldn't use it with the main portage tree. Unless there's a way to do |
13 |
> this in stock portage? I don't have any experience with the python side of |
14 |
> portage, so please enlighten my ignorance... |
15 |
Python side of it isn't really required, just how I wrote it |
16 |
originally. In hindsight, it's bound much too tightly to my daemon |
17 |
code, should loosen sandbox's treatment of LD_PRELOAD and split |
18 |
confcache into a seperate script/prog. Course that introduces security |
19 |
issues, although going userpriv + fakeroot ought to help that (playing |
20 |
with that now). |
21 |
|
22 |
> > Also, variables changing _will_ cause |
23 |
> > configure to bail if they've been cached (cflags fex), so you might want |
24 |
> > to either filter those entries (they start with ac_cv_env_), or rewrite |
25 |
> > them (I went for rewrite, works although I worry about other cache |
26 |
> > entries relying on the vars not changing). |
27 |
> I dump the cache when they change in the latest revision of my patch. That |
28 |
> seems safest. The problem is that some ebuilds (eg fftw) modify CFLAGS, thus |
29 |
> invalidating the cache. |
30 |
> |
31 |
> How safe do you think it is to ignore these variables entirely? Some of them |
32 |
> like LDFLAGS might affect the results of some configure tests. We could have |
33 |
> separate cache data for different combinations of them... |
34 |
If the variables change, autoconf catches it- causes the configure to |
35 |
bail unfortunately. They must be dealt with in some way, although I'm |
36 |
starting to think filtering them from the cache is a better approach |
37 |
them rewriting them. |
38 |
|
39 |
> |
40 |
> > Aside from that, there is also the md5'ing of /proc/cpuinfo- most users, |
41 |
> > not an issue, as magnade pointed out, this is a killer for users that |
42 |
> > have procs that adjust their frequency (laptops fex) for power saving- |
43 |
> > this changes the md5 of /proc/cpuinfo pretty much continually, |
44 |
> > invalidating the cache continually. |
45 |
> |
46 |
> We'll have to add special treatment for it then. |
47 |
Haven't really figured out a sane way to do special treatment- a good |
48 |
portion of /proc and /sys will likely require special handling. |
49 |
Thoughts? |
50 |
|
51 |
Not much for just defining a bunch of special cases, but doesn't really |
52 |
seem to be any other way. |
53 |
~brian |
54 |
|
55 |
|
56 |
-- |
57 |
gentoo-portage-dev@g.o mailing list |