View previous topic :: View next topic |
Author |
Message |
inf1nity n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Apr 2015 Posts: 15
|
Posted: Mon Jun 17, 2024 10:21 am Post subject: Binary package host: when clients dont install all pkgs |
|
|
Hi,
I've been running my own binary package host for some time now and mostly it's working really well.
However, sometimes I have problems when "client" systems don't have all packages installed, that the binary package host has. This leads to strange blockers and or packages that would have to be built on the client.
For example if package A, not installed on a client, requires an older version of package B, thus preventing an upgrade to a newer available version for B on the binary package host, then said package B would be eligible for upgrade on the client system, as A is not installed and blocking the upgrade.
As far as I can figure out, the only way to make it consistent would be to always, after everything has been updated on the binary package host, create a package.mask file, that would list all available newer versions of installed packages.
Does such a script, for creating a list of all available newer versions of installed packages, already exist somewhere and if not, could someone please point me in the right direction? Especially comparing package versions is something I'm unsure on how to do reliably, i.e. does a developer tool for something like this exist, that works with the exact gentoo version format? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
logrusx Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
![](images/avatars/176594205966916859b5145.jpg)
Joined: 22 Feb 2018 Posts: 2149
|
Posted: Mon Jun 17, 2024 11:23 am Post subject: |
|
|
I think emerge --getbinpkgonly, on the client, is what you're looking for.
Best Regards,
Georgi |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
eschwartz Developer
![Developer Developer](/images/ranks/rank-dev.gif)
![](images/avatars/180460208566750902dba46.png)
Joined: 29 Oct 2023 Posts: 131
|
Posted: Mon Jun 17, 2024 1:14 pm Post subject: |
|
|
Ideally a binhost builder would have minimal packages in its world file so that it can resolve and install any package without worrying about conflicting requirements.
You can then regularly depclean whenever it has blocker issues, generate a new binary package for whatever the problematic package is, and move on. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
pjp Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/1154772887439692d88303b.jpg)
Joined: 16 Apr 2002 Posts: 20329
|
Posted: Mon Jun 17, 2024 4:54 pm Post subject: |
|
|
Are you keeping the client's repositories, world file and /etc/portage directory structure in sync with the binhost? If not, that can cause some problems. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
NeddySeagoon Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/3946266373f47d606a2db3.jpg)
Joined: 05 Jul 2003 Posts: 54528 Location: 56N 3W
|
Posted: Mon Jun 17, 2024 5:25 pm Post subject: |
|
|
inf1nity,
Build time dependencies will not be installed on binhost clients by default. They are not needed until the client needs to build something.
You can ask for build time dependencies with --with-bdeps=y, _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
inf1nity n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Apr 2015 Posts: 15
|
Posted: Mon Jun 17, 2024 7:36 pm Post subject: |
|
|
First of all, thank you all for your help, explanations and input!!
I'll try to clarify:
I'm keeping all clients /etc/portage directory in sync (EDIT: with the binhosts), while allowing slight overrides via .local files that aren't synchronized/deleted upon synchronization. One such example is a make.conf.local that helps me use different FEATURES, EMERGE_DEFAULT_OPTS, etc between binhost and client.
Like on the client:
FEATURES="${FEATURES} getbinpkg pkgdir-index-trusted"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --rebuilt-binaries"
Every time I upgrade the binary package host, I create a snapshot of the /etc/portage and /var/cache/binpkgs directories and sync them to a mirror server. From there the former is rsync'ed and the latter used as a http binrepo.
I have two binary package hosts, one for a server environment and one for desktop. What I don't keep in sync is the world file, however I make sure that it is nearly identical, to avoid unncessary blockers, use flag issues, etc. The clients world file is always a subset of the binhosts.
That works mostly fine, except for cases where not-installed packages lead to different dependency resolutions, which is exactly why I created my post, as I'm searching for a solution.
Regarding the info from @eschwartz, do I understand that correctly, that only a very minimal system should be in the world file and other packages I want to be provided by the binhost are to be installed with some form of build-package-only? Does this also hold true for bigger things like KDE/Plasma?
At the moment I'm just adding all packages that I need in the binhosts world file, so that if the binhost is in a consistent state, I can assume that the clients will be as well ...
I hope that is reasonable.
I'll take a look at emerge --getbinpkgonly later. It could be what I need, but I'm unsure solely from reading the manpages.
@NeddySeagoon: I'm aware, but this was a runtime dependency. Just to make sure I looked in the world file, it's not there, and it is also not being removed by running
emerge -av --depclean --with-bdeps=n
If my approach to using binhosts is off, please let me know ...
Thanks again! |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
eschwartz Developer
![Developer Developer](/images/ranks/rank-dev.gif)
![](images/avatars/180460208566750902dba46.png)
Joined: 29 Oct 2023 Posts: 131
|
Posted: Mon Jun 17, 2024 8:34 pm Post subject: |
|
|
inf1nity wrote: |
Regarding the info from @eschwartz, do I understand that correctly, that only a very minimal system should be in the world file and other packages I want to be provided by the binhost are to be installed with some form of build-package-only? Does this also hold true for bigger things like KDE/Plasma?
At the moment I'm just adding all packages that I need in the binhosts world file, so that if the binhost is in a consistent state, I can assume that the clients will be as well ...
|
The thing is that binpackages are just a cache where the key is "cat/pkg-version + ACTIVE_USE_FLAGS + DEPS".
You can have many binpackages for a single package, and you'll only download whichever one is compatible with your current USE flags, installed dependencies, world file, etc. If you compile a package for the server and happen to have matching USE flags with the desktop host, it is 100% okay to reuse the existing binpackage.
For example, the Gentoo official binhost has:
profiles, each of which are a separate build container. But they mount the same /var/cache/binpkgs for all build containers. Each profile builds a set of packages with the default USE flags for e.g. the desktop/gnome or desktop/plasma profile. The end result is a single "amd64" HTTP binrepo. It uses world files to track which packages should be built and updated regularly to make new binpackages.
It's simple to just ssh into the binhost, and build a single package you really want with USE="some particular USE flags" emerge --oneshot cat/pkg. You can uninstall it after, and you still have the binpackage.
Or, you can have a cron job that one-shot installs packages that have valid rebuilds with -uDU --keep-going=y, and when anything fails to build, depclean and try again. The only thing that matters is that the system can always be returned to a valid state to queue more builds, and that it builds reusable binpackages. So you can experiment with different combinations that aren't necessarily valid *at the same time*.
You can also build individual packages with --buildpkgonly, which doesn't install the package but does compile it and add it to /var/cache/binpkgs. But it will be unable to compile packages if they have BDEPEND or DEPEND that aren't installed. You can build a binary package without installing it like this:
Code: |
emerge --onlydeps cat/foobar
emerge --buildpkgonly cat/foobar
|
|
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
inf1nity n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Apr 2015 Posts: 15
|
Posted: Tue Jun 18, 2024 8:07 am Post subject: |
|
|
@eschwartz:
Thank you very much! Now I finally understand how this works.
Though if I were to build packages optimized for different CPU architectures, then I'd need to have separate binhost VMs and binrepos, correct? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22366
|
Posted: Tue Jun 18, 2024 11:55 am Post subject: |
|
|
You can use a single VM to host more than one binrepo. At worst, you might need the VM to have a separate chroot for each binrepo.
For most people, the overhead of maintaining multiple highly similar binrepos is worse than the tiny performance loss of using a single binrepo that is compatible with all the client machines. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
eschwartz Developer
![Developer Developer](/images/ranks/rank-dev.gif)
![](images/avatars/180460208566750902dba46.png)
Joined: 29 Oct 2023 Posts: 131
|
Posted: Tue Jun 18, 2024 1:31 pm Post subject: |
|
|
The official Gentoo binhost provides baseline -march=x86-64 packages as well as optimized microarchitecture packages for -march=x86-64-v3.
This covers most use cases. You don't really need packages to be compiled with -march=native when you can get very close to that by sticking with common architecture levels such as -v3 that are easily tested for support. And it means you don't have to have 60 different binhosts, one for every unique CPU. ![Smile :)](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
inf1nity n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Apr 2015 Posts: 15
|
Posted: Tue Jun 18, 2024 7:12 pm Post subject: |
|
|
eschwartz wrote: | [...] And it means you don't have to have 60 different binhosts, one for every unique CPU. ![Smile :)](images/smiles/icon_smile.gif) |
Yeah wasn't thinking about that
But perhaps one day a Skylake and an Epyc based binhost ... I'll think about sane lowest common denominators. At the moment some older Atom based servers limit it somewhat.
As Hu pointed out:
Hu wrote: | [...] For most people, the overhead of maintaining multiple highly similar binrepos is worse than the tiny performance loss of using a single binrepo that is compatible with all the client machines. |
Which is certainly true. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
eschwartz Developer
![Developer Developer](/images/ranks/rank-dev.gif)
![](images/avatars/180460208566750902dba46.png)
Joined: 29 Oct 2023 Posts: 131
|
Posted: Tue Jun 18, 2024 7:17 pm Post subject: |
|
|
Yes, that's why the microarchitecture levels were formulated.
Code: |
$ ld.so --help
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked 'ld.so', the program interpreter for dynamically-linked
ELF programs. Usually, the program interpreter is invoked automatically
when a dynamically-linked executable is started.
[...]
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
|
Meaning that my CPU is compatible with -march=x86-64-v2 as well as -march=x86-64-v3. You can roughly group CPUs into only a small handful of groups, get *most* of the benefits of -march=native, and limit yourself to at most 4 binhosts, or depending on whether all of your machines are "either baseline x86-64 or support -v3" you can maybe get away with just two. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
logrusx Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
![](images/avatars/176594205966916859b5145.jpg)
Joined: 22 Feb 2018 Posts: 2149
|
Posted: Tue Jun 18, 2024 7:38 pm Post subject: |
|
|
eschwartz wrote: | You can roughly group CPUs into only a small handful of groups, get *most* of the benefits of -march=native, and limit yourself to at most 4 binhosts, or depending on whether all of your machines are "either baseline x86-64 or support -v3" you can maybe get away with just two. |
Not to mention Intel low power cores do not support v3, so it's mostly v2 and v3 out there. If all the clients support v3, that's almost complete win, unless somebody needs AVX512 or similar. Then you can make a binhost specifically for them.
Best Regards,
Georgi |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|