| 1 |
On 01/19/2018 07:03 AM, Anthony G. Basile wrote: |
| 2 |
> On 1/19/18 9:45 AM, Alec Warner wrote: |
| 3 |
>> On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy <billk@×××××××××.au> wrote: |
| 4 |
>> |
| 5 |
>>> On 18/01/18 23:36, Duncan wrote: |
| 6 |
>>>> Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted: |
| 7 |
>>>> |
| 8 |
>>>>> I'm trying to design an update system for many identical Gentoo systems. |
| 9 |
>>>>> Using a binhost is obvious, but there are still problems with this |
| 10 |
>>>>> approach. |
| 11 |
>>>>> |
| 12 |
>>> |
| 13 |
>>> I'd suggest go for a semi diskless OS - boot them from one central image |
| 14 |
>>> with an individual overlay filesystem with local customisations. NFS |
| 15 |
>>> mount the common directories. |
| 16 |
>>> |
| 17 |
>>> you just have a one central host to build for and don't need to worry |
| 18 |
>>> about portage everywhere. |
| 19 |
>>> |
| 20 |
>>> Worked ok with a small number of mythtv frontends. |
| 21 |
>>> |
| 22 |
>> |
| 23 |
>> It doesn't work if you have a WAN; NFS needs low latencies between the NFS |
| 24 |
>> server and the client or you will have a bad time. |
| 25 |
>> |
| 26 |
>> |
| 27 |
> |
| 28 |
> Zac pretty much nailed the requirements in bug #644990. You should not |
| 29 |
> need the portage tree at all, neither locally nor via any network |
| 30 |
> filesystem. He mentions there that it is currently possible via "a |
| 31 |
> dummy profile", but I'm not sure what he means by that yet or how to set |
| 32 |
> one up. |
| 33 |
|
| 34 |
The dummy profile consists of making a /etc/portage/make.profile/ |
| 35 |
directory that is nearly empty, containing only a make.defaults file |
| 36 |
with minimal settings like these: |
| 37 |
|
| 38 |
ARCH="amd64" |
| 39 |
ACCEPT_KEYWORDS="**" |
| 40 |
ACCEPT_LICENSE="*" |
| 41 |
|
| 42 |
You also need a big IUSE_IMPLICIT setting in there if you don't have |
| 43 |
this patch that's in portage-2.3.19: |
| 44 |
|
| 45 |
https://gitweb.gentoo.org/proj/portage.git/commit/?id=2382082dcfce5e6c2be7c4dd6aed7c32e1d20616 |
| 46 |
|
| 47 |
With the dummy profile, you can install all of the packages available in |
| 48 |
the binhost. Currently, there's not a really good way to tell emerge to |
| 49 |
install all packages from the binhost, but you can parse them all from |
| 50 |
${PORTAGE_BINHOST}/Packages and write the list to /var/lib/portage/world |
| 51 |
or something similar. Then `emerge -vuGD @world`. |
| 52 |
|
| 53 |
I've described my currently planned sequence of steps here: |
| 54 |
|
| 55 |
https://bugs.gentoo.org/644990#c3 |
| 56 |
|
| 57 |
If you try the dummy profile approach, then if there are any in-place |
| 58 |
package moves in the binhost then you may have problems with file |
| 59 |
collisions, but I've described how I plan to handle that in the above |
| 60 |
bug comment. |
| 61 |
-- |
| 62 |
Thanks, |
| 63 |
Zac |
Archives