[HALTED]I'm using emerge wrong

[coalms]

I am using gentoo as a package manager for multiple systems
If I the system allows it without bugs I use a --root on the remote system and --sysroot on a local one otherwise both pointing at the remote.
My problem is config-root, i use it to change the remote system's portage Dir location which I sometimes point at the same Dir I point sysroot when I update a split root sysroot system.
I can understand not all my system setups(20+) work fine with a split sysroot probably due to missconfigures packages I don't mind that, what gets me mad is the local /etc/portage Dir, everytime I update a remote system I have to update the local configs as well for changes in the use flags, its a bit unfortunate that I cannot change the host config root but whatevs
Do y'all think I should create a chroot for each and every system I update to avoid conflicts between multiple systems asking for different use flags from the host system OR will that cause any problems with the local binhost that they all share
Will multiple chroots running at different times corrupt the binhost or will I be able to use said binhost with respect to useflags as I always do
Lastly if anyone of you has the same use case as mine then what do you doctor conserve space? I was thinking of stacking multiple overlayfs layers and chrooting in for can update and then mount the remote NFS inside the chroot for an update.

Love y'all,

Coalms

[paulj]

I'm kind of hesitant to reply, because I am not sure why you are working this way, so my reply is not all that helpful to you yet. I have never done something like this, and to be honest don't understand why you would!
Perhaps, if you will humour me, I could ask you some questions to establish why you have ended up with this approach?

• Are you trying to avoid having multiple copies of portage across the different machines? In other words, you want to have one repository which is used by all of them.
• Are you trying to have a common environment in each of the systems, so you can move seamlessly between them? I am not sure this is the case, because you talk about differing use flags between systems.
• Are the different systems similar in capability, or are some more powerful with more resources?
• It sounds like some, or possibly even most of the systems are headless?

Hopefully some clarification will get you some additional answers about how best to approach this in a gentoo way.

[coalms]

I'm kind of hesitant to reply, because I am not sure why you are working this way, so my reply is not all that helpful to you yet. I have never done something like this, and to be honest don't understand why you would!
Perhaps, if you will humour me, I could ask you some questions to establish why you have ended up with this approach?

• Are you trying to avoid having multiple copies of portage across the different machines? In other words, you want to have one repository which is used by all of them.
• Are you trying to have a common environment in each of the systems, so you can move seamlessly between them? I am not sure this is the case, because you talk about differing use flags between systems.
• Are the different systems similar in capability, or are some more powerful with more resources?
• It sounds like some, or possibly even most of the systems are headless?

Hopefully some clarification will get you some additional answers about how best to approach this in a gentoo way.

I am trying to have a common environment, using a central pkg_Dir and I think I'll start having a common ccacge as well in a while.
I'm planning to host all musl-amd64 under one chroot and glib-amd64 on another, there will be a few opportunities in the next few months for embedding as well so I plan to split them based on arch, probably cross-compile or qemu I figure.
Most systems at the moment have the exact same capabilities in terms of specs but some indeed run headless as servers or routers for my internal networking.
I understand how unusual this use case is for portage and brought up this confusion, in the end I am just getting paid to make sure my company doesn't get hacked so package minimalism per machine is my best choise

Other then creating a different chroot per system which is inefficient -- The only "working" "solution" I have found that makes things a lot easier(based on the documentation available) is for me to use paludis rather then portage, it forces sysroot and root change even when an ebuild is misconfigured to use these flags correctly(based on the documentation) something that I have speculated was breaking my central compiling system for a while now but I wasent sure ,unfortunately I have to many files in my portage Dir that I haven't tried migrating yet, one extra positive is that paludis has a suggestions file where you can set optional flags per package which are only used when it is needed which solves a lot of time when fixing the use flags for each machine

[paulj]

I wonder whether you could approach this from a slightly different direction. Please see my post here: https://forums.gentoo.org/viewtopic-t-1169109.html, and the subsequent thread. Maybe you can use this approach to define your system specifications?

[coalms]

I wonder whether you could approach this from a slightly different direction. Please see my post here: https://forums.gentoo.org/viewtopic-t-1169109.html, and the subsequent thread. Maybe you can use this approach to define your system specifications?

Unfortunately not, I am using a semi-custom profile to begin with, my problems stem from how portage previews and defines the ROOT EROOT BROOT and SYSROOT environment variables.

You see from my experience (and please correct me if I am wrong) setting this flags on different directories will either lead portage to ignore the defined variable and use the default or won't work correctly.
Example:
I need CONFIG_ROOT and BROOT to point to a directory different from root to keep the system minimal
ROOT=/mnt/system2
BROOT=/system2
CONFIG_ROOT=/system2
This (kinda) works but when I run emerge --config-root=/system2 then portage doesn't distinguish between / and /mnt/system2
Otherwise i can set SYSROOT=/system2 as well as the environment variables listed above in which case packages for ROOT will be postfixed with " to /mnt/system2 " during emerge -vp
BUT packages for sysroot will NOT be postfixed with a path, neither packages for the live system where emerge is running for(/) so I end up mixing them up and having to guesswork if I need to update /etc/portage/package.use or /system2/etc/portage/package.use
Now keep in mind I cannot avoid updating the live system(/) when I am updating system2, now imagine when the live system has to update 20+ of these systems, the live system just breaks no doubt about it
A half broken solution is creating a chroot for each child system
Then chroot in there and do
ROOT=/mnt
SYSROOT=/
CONFIG_ROOT=/
BROOT=/
In which case I know the live system won't be affected neither will the use flags of each system affect each other because each system had its own chroot-updater(remember if I didn't use chroot I sometimes would have to update the live systems useflags, which for bdeps packages means that one system would affect each other unconditionally
You might think I have arrived at my solution but I assure you I have not.
A halfbroken solution the chroot way PLUS overlayfs from (livesystem)/etc/portage to (chroot)/etc/portage so I can share use flags between packages conditionally, which cuts emerge times when using a pkgdir

There is always a BUY tho, I cannot put my finger on to why but my experience using and abusing portage badly for years gives me this tingly feeling that some breakages that happen are because of that of how portage handles things
Keep in mind I am trying for over a year now and playing with different ROOT BROOT EROOT CONFIG_ROOT and SYSROOT flags
I even thought of making my own emerge command but with all honesty portage's codebase is a headache to crack and I pay huge respect to contributors, been pondering to swap it with pkgcore or paludis about a month but I just fear for future robustness

I'm thinking of pulling a list of all BDEPS from all my systems and sort it out so I can create a global bdep useflag file to cut down emerge times

Don't know if I have explained it correctly but /mnt/system2 is a detachable standalone system, it should have only rdeps and the @world+@system (in any case @selected) installed into it, system2 could be a rescueusb, a headless server, a router or even a gaming system. I am thinking of using NFS for my local network and having local machines use that, the central compiling system that I am building just has to act as the builder and upkeeper of said systems.

If you have any insight or my use case please do tell me

Cheers

Coalms

[NeddySeagoon]

coalms,

Let me throw a rock in the pool. It's not a complete solution, at least, I don't think it is.
Suppose, on the build host, /etc/portage and /var/lib/portage/world are symbolic links.
Further the are links to /etc/portage_systemN and /var/lib/portage/world_systemN where N goes from 1..sysy_max.

Now the build host has copies of what and how things are installed on all of your target systems.
A wrapper script to manage these things would be good.

You set FEATURESE="buildpkg-multi-instance" so you get a binhost of binary packages to suit all of your systems.
Check that option name.

On the build box, you choose a system to build for and run emerge -uDUavk @world --keep-going
The -k matters. That exploits similarities between systems to avoid repeatedly building the same thing.
If you feel lucky, try adding --buildpkgonly but that requires that all dependencies are already installed.

Once complete, you have a binhost to suit all of your systems.

Distribute the ::gentoo repo and binhost to the targets however you like, as long as it meets your security constraints, then emerge the binaries on the targets. That needs emerge -K or emerge -G, depending on how you distribute things.

-- edit --
A couple of inmrovements

1. it's safer to do all this building in a single choot or it will make a mess of the build host.

2. The first runs will need emerge -e to get everything into the binhost, with -k if you like too.

3. The buildhosts repo(s) distfiles and packages can be shared with the chroot.

[coalms]

coalms,

Let me throw a rock in the pool. It's not a complete solution, at least, I don't think it is.
Suppose, on the build host, /etc/portage and /var/lib/portage/world are symbolic links.
Further the are links to /etc/portage_systemN and /var/lib/portage/world_systemN where N goes from 1..sysy_max.

Now the build host has copies of what and how things are installed on all of your target systems.
A wrapper script to manage these things would be good.

You set FEATURESE="buildpkg-multi-instance" so you get a binhost of binary packages to suit all of your systems.
Check that option name.

On the build box, you choose a system to build for and run emerge -uDUavk @world --keep-going
The -k matters. That exploits similarities between systems to avoid repeatedly building the same thing.
If you feel lucky, try adding --buildpkgonly but that requires that all dependencies are already installed.

Once complete, you have a binhost to suit all of your systems.

Distribute the ::gentoo repo and binhost to the targets however you like, as long as it meets your security constraints, then emerge the binaries on the targets. That needs emerge -K or emerge -G, depending on how you distribute things.

-- edit --
A couple of inmrovements

1. it's safer to do all this building in a single choot or it will make a mess of the build host.

2. The first runs will need emerge -e to get everything into the binhost, with -k if you like too.

3. The buildhosts repo(s) distfiles and packages can be shared with the chroot.

NeddySeagoon,

That is very close to how this project started as a whole, although I have to say you just solved me weeks of compiling because I had set binpkg-multi-instance not build pkg a multi constance, thank you truly.

On another when I traverse to having unified bdeps useflags for all my chroots its going to be close to what you are trying to describe but there is one thing that I would like some clarification on, you say it is safer to do all the building in a single chroot, while from my experience I have experienced the opposite to be true for stability probably stemming from incompatible bdep use flags, I thought using a template chroot and overlaying that to another directory (say webserver_constructor) and then overlaying /etc/portage in there would harmonize things and make them more robust, could you elaborate a little more on that?

Cheers,

Coalms

[NeddySeagoon]

coalms,

I need to do a little testing but I think that's what the emerge -k and buildpkg-multi-instance takes care of.
The output is the binhost. Not the chroot itself, which can be in a mess.
The next build will do whatever it needs to do.

The -k uses existing binaries, so you don't build the toolchain for each system, among other things.

When you deploy from a binhost, you do not deploy build time dependencies, unless you ask.
I don't know how the binhost project handles differing {conflicting) build time dependencies.

I do know that several organisations using Gentoo in prodution, build in a test environment and distribute tested build products.
They use Gentoo to roll their own in house binary distro, in effect.
It's a good idea to minimise the number of configurations you need.

[coalms]

coalms,

I need to do a little testing but I think that's what the emerge -k and buildpkg-multi-instance takes care of.
The output is the binhost. Not the chroot itself, which can be in a mess.
The next build will do whatever it needs to do.

The -k uses existing binaries, so you don't build the toolchain for each system, among other things.

When you deploy from a binhost, you do not deploy build time dependencies, unless you ask.
I don't know how the binhost project handles differing {conflicting) build time dependencies.

I do know that several organisations using Gentoo in prodution, build in a test environment and distribute tested build products.
They use Gentoo to roll their own in house binary distro, in effect.
It's a good idea to minimise the number of configurations you need.

NeddySeagoon,

Sorry for the confusion I already knew how a local binhost works just about at the intermediat level,

What interests me tho is how you said orgs organize their gentoo "custom distros", if you have any details to further explain the plan such orgs follow or if ( it is respectfully allowed that ) you to give me the email of someone in such an org so I can ask a few questions that would be much appreciated, although for the latter I understand if such an admin wouldn't want to share their details. Otherwise I will halt this discussion here and create a new post (hopefully a guide) when I figure this out on my own, nevertheless this thread has been a good haul.

PS thank you @paulj as well for your input

Cheers,

Coalms

[NeddySeagoon]

coalms,

The only public description I know of appeared in The Gentoo Weekly Newsletter a long time ago.
So long ago, it may have been the Monthly Newsletter.

I don't have any contact details.

Essenially, the orgs I know of do the same thing as described in the newsletter.
Build and test in a test environmet. Freeze their copy of the repos when they are happy that what they have in the test environment is production ready. The deploy the (frozen) repo(s) and binhost to production.

I'll try to get a link to the GWN when I'm not using my phone

[coalms]

coalms,

The only public description I know of appeared in The Gentoo Weekly Newsletter a long time ago.
So long ago, it may have been the Monthly Newsletter.

I don't have any contact details.

Essenially, the orgs I know of do the same thing as described in the newsletter.
Build and test in a test environmet. Freeze their copy of the repos when they are happy that what they have in the test environment is production ready. The deploy the (frozen) repo(s) and binhost to production.

I'll try to get a link to the GWN when I'm not using my phone

NeddySeagoon,

Brilliant, they essentialy create a stable-release as opposed to a rolling release repository to avoid mass "corruption", I imagine running updates once every 3-6 months and -vau @security probably daily or bi-daily, effectively creating their own distribution and using gentoo's stability and security as a backbone.
Even if you don't find the original newsletter you have given me quite a few ideas on how I should stably handle things, I am extremely happy with this info, thank you Neddy

Best wishes, and thank you for making my day,

Coalms