| 1 |
Greetz, |
| 2 |
|
| 3 |
For some time now (going on two years), our company has been using the |
| 4 |
binary package server functionality of portage to maintain a build server. |
| 5 |
We have 20+ Gentoo servers that have been built using binary packages from |
| 6 |
the build server and have had relatively good success maintaining the |
| 7 |
systems this way. The goals we were trying to meet under this architecture |
| 8 |
were quick deployments and updates by using binary packages, and |
| 9 |
consistent software configurations across all systems. |
| 10 |
|
| 11 |
Recently we've been having doubts as to the maintainability of this setup. |
| 12 |
For example, new installations will synchronize with the Portage tree on |
| 13 |
the build server (so they both have the same "view" of Portage and the |
| 14 |
client can never jump ahead of the build server; that would be a Bad |
| 15 |
Thing.) When a new installation takes place, the client will try to pull |
| 16 |
the latest stable versions of any package from the build server. This |
| 17 |
means that our build server must stay updated constantly, even for |
| 18 |
packages that you would not normally be updating religously, such as |
| 19 |
libraries that only serve as dependencies for mainstream applications. Due |
| 20 |
to the architecture, this seems to be a neccesary evil. It's just hard to |
| 21 |
identify the packages that need updated on build server before we see a |
| 22 |
client try to install it and not find the latest package. Something we'd |
| 23 |
considered was frequent 'emerge -uD' on the server to make sure packages |
| 24 |
were updated. Any advice on this? |
| 25 |
|
| 26 |
The real meat of this posting is the problems we've had recently trying to |
| 27 |
update mod_php on some of our web servers. There were a lot of broken |
| 28 |
library links because of dependencies that were not being met once the new |
| 29 |
binary package was merged into the system, since on the build server it |
| 30 |
was built against new versions of dependencies (libraries) that were |
| 31 |
present on the client; for example, the build server had mysql-4.1 which |
| 32 |
is what mod_php was built against, but the client would only be running |
| 33 |
mysql-4.0.x and would therefore have linker errors. We just couldn't catch |
| 34 |
this beforehand because portage has no way of knowing to automatically |
| 35 |
grab dependencies in this case... |
| 36 |
|
| 37 |
Is this matter one that we'll have to put more effort into managing? Is |
| 38 |
there an easy solution? Maybe something that could be solved by emerging |
| 39 |
packages using a deeper dependency tree, and if so, what would be safe for |
| 40 |
long term use? |
| 41 |
|
| 42 |
DS |
| 43 |
-- |
| 44 |
gentoo-server@g.o mailing list |
Archives