Red Hat Bugzilla – Bug 442323
removal of client package breaks bcfg2-server package modules
Last modified: 2008-04-14 09:06:27 EDT
Description of problem: a) server depends on client, considering that there are problems in packaging, you probably don't want problems to reconfigure your production server. So far it appears, that there is no technical reason (that is, like module dependency) to make them to depend on each other. (judging it by rpm -ql listing) b) Removing it using --nodeps breaks the bcfg2-server package's modules for no reason. # rpm -qf /usr/lib/python2.4/site-packages/Bcfg2/__init__.py bcfg2-0.9.5.7-1.el5 # rpm -e bcfg2 --nodeps # service bcfg2-server start Starting bcfg2-server: Traceback (most recent call last): File "/usr/sbin/bcfg2-server", line 6, in ? import Bcfg2.Server.Plugins.Metadata ImportError: No module named Bcfg2.Server.Plugins.Metadata Version-Release number of selected component (if applicable): reinstalling the client fixes the issue. How reproducible: always. Steps to Reproduce: 1. rpm -e --nodeps bcfg2 2. service bcfg2-server restart 3. bang Actual results: traceback Expected results: you don't need to install web browser in order to have apache running in your server, why would you need a configuration client. Additional info: I guess splitting up the python module dirs to Bcfg2 --> Bcfg2-Client,Bcfg2-Server would allow both have their own __init__.py files and remove the pkg dependency. That's probably an upstream change (imports, install)
If you don't want to run the configuration client on your server, there are methods within Bcfg2 to disable the client and preventing it from making any changes on the server. Until upstream reorganizes the code, it makes sense to put all of the common code into the client package and have the server package require it. That's something that you should discuss directly with upstream: http://trac.mcs.anl.gov/projects/bcfg2/wiki/MailingList I've found them to be extremely receptive to well-reasoned arguments, especially if accompanied by patches.
in IRC i got some explanation: That isn't really a fixable problem. we can change things so that we had a separate path to server and client modules, but the server depends on modules included in the client as well and in some cases, there is a hard (versioned) dependency between the server and client code so the server dependency on the client is really there for a reason.
Well, this is common problem and like in samba, it has samba-common pkg for shared stuff and they all are distributed together, under a same version. It's just a matter of making it possible to split them into different pkgs with the installation.