| 1 |
On Tue, Jul 31, 2012 at 10:48 AM, "Paweł Hajdan, Jr." |
| 2 |
<phajdan.jr@g.o> wrote: |
| 3 |
> On 7/26/12 8:26 PM, Rich Freeman wrote: |
| 4 |
>> I've been messing around with namespaces and some of what systemd has |
| 5 |
>> been doing with them, and I have an idea for a portage feature. |
| 6 |
>> |
| 7 |
>> But before doing a brain dump of ideas, how useful would it be to have |
| 8 |
>> a FEATURE for portage to do a limited-visibility build? That is, the |
| 9 |
>> build would be run in an environment where the root filesystem appears |
| 10 |
>> to contain everything in a DEPEND (including @system currently) and |
| 11 |
>> nothing else? |
| 12 |
> |
| 13 |
> I was thinking about something similar too. In my opinion it's a great |
| 14 |
> feature. If/when there are any bugs to get this implemented, please let |
| 15 |
> me know. |
| 16 |
> |
| 17 |
> A possible alternative implementation would be to make the sandbox deny |
| 18 |
> access to anything outside DEPEND. One totally crazy idea to make that |
| 19 |
> fast are extended attributes (portage would record which package a file |
| 20 |
> belongs to when merging the file). Another possible solution is using a |
| 21 |
> cache. |
| 22 |
|
| 23 |
We already have the ability to run commands like 'equery b $somefile' |
| 24 |
to map a file back to a package, so the data for a filesystem helper |
| 25 |
should already be available in whatever database equery is using. |
| 26 |
|
| 27 |
-- |
| 28 |
:wq |
Archives