Greetz,

For some time now (going on two years), our company has been using the
binary package server functionality of portage to maintain a build server.
We have 20+ Gentoo servers that have been built using binary packages from
the build server and have had relatively good success maintaining the
systems this way. The goals we were trying to meet under this architecture
were quick deployments and updates by using binary packages, and
consistent software configurations across all systems.

Recently we've been having doubts as to the maintainability of this setup.
For example, new installations will synchronize with the Portage tree on
the build server (so they both have the same "view" of Portage and the
client can never jump ahead of the build server; that would be a Bad
Thing.) When a new installation takes place, the client will try to pull
the latest stable versions of any package from the build server. This
means that our build server must stay updated constantly, even for
packages that you would not normally be updating religously, such as
libraries that only serve as dependencies for mainstream applications. Due
to the architecture, this seems to be a neccesary evil. It's just hard to
identify the packages that need updated on build server before we see a
client try to install it and not find the latest package. Something we'd
considered was frequent 'emerge -uD' on the server to make sure packages
were updated. Any advice on this?

The real meat of this posting is the problems we've had recently trying to
update mod_php on some of our web servers. There were a lot of broken
library links because of dependencies that were not being met once the new
binary package was merged into the system, since on the build server it
was built against new versions of dependencies (libraries) that were
present on the client; for example, the build server had mysql-4.1 which
is what mod_php was built against, but the client would only be running
mysql-4.0.x and would therefore have linker errors. We just couldn't catch
this beforehand because portage has no way of knowing to automatically
grab dependencies in this case...

Is this matter one that we'll have to put more effort into managing?  Is
there an easy solution? Maybe something that could be solved by emerging
packages using a deeper dependency tree, and if so, what would be safe for
long term use?

DS
--
[email protected] mailing list

Reply via email to