Re: [gentoo-portage-dev] re: confcache

[Brian Harring <ferringb@gentoo.org>]

On Sat, 2004-10-09 at 02:45, Dan Armak wrote:
> On Friday 08 October 2004 22:08, Brian Harring wrote:
> > Well... that's weird, attempted to send this directly to dan, having it
> > bail due to
> > 'failed: relaying not allowed: danarmak@gentoo.org'
> > I assume I'm being an idiot and screwing up the address (or local
> > configuration)...
> All I can say is, I can receive at that address quite well...
Don't worry about it, I was being an idiot (usually a valid assumption).

> I did, but it's tied to your ability to call back into python from ebuild.sh, 
> so I couldn't use it with the main portage tree. Unless there's a way to do 
> this in stock portage? I don't have any experience with the python side of 
> portage, so please enlighten my ignorance...
Python side of it isn't really required, just how I wrote it
originally.  In hindsight, it's bound much too tightly to my daemon
code, should loosen sandbox's treatment of LD_PRELOAD and split
confcache into a seperate script/prog.  Course that introduces security
issues, although going userpriv + fakeroot ought to help that (playing
with that now).

> > Also, variables changing _will_ cause 
> > configure to bail if they've been cached (cflags fex), so you might want
> > to either filter those entries (they start with ac_cv_env_), or rewrite
> > them (I went for rewrite, works although I worry about other cache
> > entries relying on the vars not changing).
> I dump the cache when they change in the latest revision of my patch. That 
> seems safest. The problem is that some ebuilds (eg fftw) modify CFLAGS, thus 
> invalidating the cache.
> 
> How safe do you think it is to ignore these variables entirely? Some of them 
> like LDFLAGS might affect the results of some configure tests. We could have 
> separate cache data for different combinations of them...
If the variables change, autoconf catches it- causes the configure to
bail unfortunately.  They must be dealt with in some way, although I'm
starting to think filtering them from the cache is a better approach
them rewriting them.

> 
> > Aside from that, there is also the md5'ing of /proc/cpuinfo- most users,
> > not an issue, as magnade pointed out, this is a killer for users that
> > have procs that adjust their frequency (laptops fex) for power saving-
> > this changes the md5 of /proc/cpuinfo pretty much continually,
> > invalidating the cache continually.
> 
> We'll have to add special treatment for it then.
Haven't really figured out a sane way to do special treatment- a good
portion of /proc and /sys will likely require special handling. 
Thoughts?

Not much for just defining a bunch of special cases, but doesn't really
seem to be any other way.
~brian


--
gentoo-portage-dev@gentoo.org mailing list