On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenvicius <a...@gentoo.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 31/07/12 10:55 AM, Michael Mol wrote: >> On Tue, Jul 31, 2012 at 10:48 AM, "Paweł Hajdan, Jr." >> <phajdan...@gentoo.org> wrote: >>> On 7/26/12 8:26 PM, Rich Freeman wrote: >>>> I've been messing around with namespaces and some of what >>>> systemd has been doing with them, and I have an idea for a >>>> portage feature. >>>> >>>> But before doing a brain dump of ideas, how useful would it be >>>> to have a FEATURE for portage to do a limited-visibility build? >>>> That is, the build would be run in an environment where the >>>> root filesystem appears to contain everything in a DEPEND >>>> (including @system currently) and nothing else? >>> >>> I was thinking about something similar too. In my opinion it's a >>> great feature. If/when there are any bugs to get this >>> implemented, please let me know. >>> >>> A possible alternative implementation would be to make the >>> sandbox deny access to anything outside DEPEND. One totally crazy >>> idea to make that fast are extended attributes (portage would >>> record which package a file belongs to when merging the file). >>> Another possible solution is using a cache. >> >> We already have the ability to run commands like 'equery b >> $somefile' to map a file back to a package, so the data for a >> filesystem helper should already be available in whatever database >> equery is using. >> > > Although that is true, it would be -WAY- too slow to generate said > list via equery/q* helpers; I think that's where the > extended-attributes and/or cache idea comes into play.
Yeah, I was thinking you could use the equery database to initially fill the cache. Spawning an equery instance for every file access would be absolute madness. I have enough entropy problems on my system. -- :wq