1 |
On 01/20/2018 07:34 AM, Anthony G. Basile wrote: |
2 |
> On 1/19/18 10:03 AM, Anthony G. Basile wrote: |
3 |
>> |
4 |
>> Zac pretty much nailed the requirements in bug #644990. You should not |
5 |
>> need the portage tree at all, neither locally nor via any network |
6 |
>> filesystem. He mentions there that it is currently possible via "a |
7 |
>> dummy profile", but I'm not sure what he means by that yet or how to set |
8 |
>> one up. I'll read his bug #640318 and try to figure it out. |
9 |
>> |
10 |
>> Thanks guys, I'm glad people at least recognized the usefulness of such |
11 |
>> a possibility. |
12 |
>> |
13 |
> |
14 |
> Okay, I have a workable solution to my question. I was able to get |
15 |
> binhost working with a portage tree containing ONLY /profiles and |
16 |
> /eclass. That's 12MB and 2.8MB in size, respectively, and I can |
17 |
> probably dump a bunch of the unused profile directories slimming that |
18 |
> down. With just those two directories in PORTDIR, emerge -K pulls down |
19 |
> the update packages from BINHOST and installs them. |
20 |
> |
21 |
> @zac any comments about this approach? Is it likely to break? |
22 |
|
23 |
It's desirable to rely exclusively on the BINHOST as a single source of |
24 |
truth, since otherwise you have to keep multiple data sources in |
25 |
consistent states. |
26 |
|
27 |
You should not need the eclasses, since portage uses the eclass code |
28 |
from environment.bz2 that is embedded in each binary package. |
29 |
|
30 |
Using /profiles can cause problems because things like package.mask and |
31 |
package.keywords have to be consistent with the BINHOST. |
32 |
|
33 |
For the above reasons, I use a dummy profile. I also sync |
34 |
/profiles/updates so that emerge can apply package moves, but I intend |
35 |
to eliminate that as part of bug #644990 since keeping /profiles/updates |
36 |
consistent with the binhost is not practical. |
37 |
-- |
38 |
Thanks, |
39 |
Zac |