| 1 |
Hi Fabian, |
| 2 |
|
| 3 |
On Jun 24, 2008, at 11:50 PM, Fabian Groffen wrote: |
| 4 |
> Portage is not designed to be "handed over" to anyone. However, there |
| 5 |
> should be just one place in Portage itself where the user is set (this |
| 6 |
> pym/portage/const_autotool.py). It may implicitly encode it in |
| 7 |
> installed packages, but this is due to the nature of those packages |
| 8 |
> that |
| 9 |
> do that themselves. |
| 10 |
|
| 11 |
Fair enough, but couldn't that script just set it to ${USER}? Is there |
| 12 |
something unsafe about that? |
| 13 |
|
| 14 |
> Maybe one of the two following things is interesting to you: |
| 15 |
> - binary packages |
| 16 |
> Prefix Portage can install from binary packages made for "another" |
| 17 |
> Prefix. You could use them to get each developer to quickly get up |
| 18 |
> to |
| 19 |
> speed, in their own Prefix installation. |
| 20 |
|
| 21 |
Actually, that's a really good idea, I hadn't thought of using binary |
| 22 |
packages with prefix. |
| 23 |
|
| 24 |
I'm in the process of moving management of our servers into puppet (http://puppet.reductivelabs.com/ |
| 25 |
), which I'm also using to distribute our overlay. There's no reason |
| 26 |
our prefixed installs couldn't use this as well, allowing us to ensure |
| 27 |
that everyone has the right version of the core dependencies of our |
| 28 |
project (installed via binary package) without blowing away anything |
| 29 |
they might have going on. |
| 30 |
|
| 31 |
Thanks to all contributers for your work, it's really nice to be able |
| 32 |
to manage my OS X box with the tools I already know. |
| 33 |
|
| 34 |
Peter |
| 35 |
-- |
| 36 |
gentoo-alt@l.g.o mailing list |
Archives