Bug 462906 - spacewalk-backend doesn't require spacewalk-backend*
Summary: spacewalk-backend doesn't require spacewalk-backend*
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 0.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Justin Sherrill
URL:
Whiteboard:
Depends On:
Blocks: space13
TreeView+ depends on / blocked
 
Reported: 2008-09-19 16:00 UTC by Justin Sherrill
Modified: 2010-11-27 17:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-27 17:46:59 UTC
Embargoed:


Attachments (Terms of Use)

Description Justin Sherrill 2008-09-19 16:00:59 UTC
Pulling down spacewalk-backend should also pull down all the spacewalk-backend* packages, but it currently doesn't.

Comment 1 Clifford Perry 2008-09-19 18:34:08 UTC
Jan or Prad - care to take a stab at this one?

Comment 2 Jan Pazdziora 2008-09-22 15:07:18 UTC
I do not think we want for spacewalk-backend to pull in any of the spacewalk-backend-* packages. I listed all the scripts in spacewalk-backend

# rpm -ql spacewalk-backend | grep '\.py$'
/usr/share/rhn/common/RPC_Base.py
/usr/share/rhn/common/UserDictCase.py
/usr/share/rhn/common/__init__.py
/usr/share/rhn/common/rhnApache.py
/usr/share/rhn/common/rhnCache.py
/usr/share/rhn/common/rhnConfig.py
/usr/share/rhn/common/rhnException.py
/usr/share/rhn/common/rhnFlags.py
/usr/share/rhn/common/rhnLib.py
/usr/share/rhn/common/rhnLockfile.py
/usr/share/rhn/common/rhnLog.py
/usr/share/rhn/common/rhnMail.py
/usr/share/rhn/common/rhnRepository.py
/usr/share/rhn/common/rhnTB.py
/usr/share/rhn/common/rhnTranslate.py
/usr/share/rhn/common/rhn_fcntl.py
/usr/share/rhn/common/rhn_mpm.py
/usr/share/rhn/common/rhn_posix.py
/usr/share/rhn/common/rhn_rpm.py
/usr/share/rhn/common/rhn_timer.py

and the only thing that needs to be added to the prerequisites is mod_python for common.rhnApache:

# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.RPC_Base ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.UserDictCase ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnApache ;'
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/share/rhn/common/rhnApache.py", line 25, in ?
    from mod_python import apache
ImportError: No module named mod_python
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnCache ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnConfig ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnException ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnFlags ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnLib ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnLockfile ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnLog ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnMail ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnRepository ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnTB ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnTranslate ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhn_fcntl ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhn_mpm ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhn_posix ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhn_rpm ;'
# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhn_timer ;'
#

Now, after installing mod_python, the thing fails with

# python -c 'import sys ; sys.path.append("/usr/share/rhn") ; import common.rhnApache ;'
Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/usr/share/rhn/common/rhnApache.py", line 25, in ?
    from mod_python import apache
  File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 28, in ?
    import _apache
ImportError: No module named _apache
# less /usr/share/rhn/common/rhnApache.py

We have a stub of _apache.py in backend's source but we do not seem to package it ...

Justin, why do you think that spacewalk-backend should Require spacewalk-backend-*?

Comment 3 Justin Sherrill 2008-09-22 20:28:28 UTC
Hi Jan,

Pradeep and I ran across this when pushing new backend packages for the NEVRA issue. 

Since all the packages are built from the same SRPM, it makes sense that they are 'bundled', such that if you install one it will install the rest.

Comment 4 Jan Pazdziora 2008-09-23 08:16:37 UTC
(In reply to comment #3)
> Since all the packages are built from the same SRPM, it makes sense that they
> are 'bundled', such that if you install one it will install the rest.

Why should the user be forced to install all packages when she only wants one? That example with imports shows that those "child" packages are not requires. That "bundle" package is spacewalk which should Require all necessary packages, not spacewalk-backend.

That "same srpm" argument is not valid -- think about httpd and httpd-manual and httpd-devel -- built from one srpm, but installing httpd does not enforce the installation of the rest. If installing spacewalk-backend should enforce install of the other packages, why do we have that package split into multiple ones in the first place? Let's just ditch spacewalk-backend-* altogether and just have one spacewalk-backend.

Alternatively we can rename the (target) spacewalk-backend to spacewalk-backend-common, so that the srpm spacewalk-backend would not generate spacewalk-backend rpm at all, so that it does not "feel" like a bundle, and does not make people confused.

Comment 5 Pradeep Kilambi 2008-09-23 14:35:51 UTC
Jan:

I don't think user would want to jus install that one pkg, as that pkg doesn't give anything useful to the user to work with. They cannot do anything with that one single package on the backend as it has jus the common modules. We could rename it to -common, I'm ok with that. But, Pulling all the spacewalk-backend-* as a dependency to spacewalk-backed.rpm makes sense to me. As the user will be installing the whole backed as the name suggests. What use case where you thinking where a user would jus want to install that one single package? that doesn't give anything to work with. don't you think?

Comment 6 Jan Pazdziora 2008-09-23 14:52:08 UTC
It is not the purpose of Requires in .spec to specify packages that the user _might like_ to have installed as well.

The Requires should be used to specify dependencies, technical dependencies. Not our idea of how the user will want to use the software. Will the user be able to have a usable product by installing (only) spacewalk-backend* packages? I guess not. The usable product is called (= as rpm) spacewalk, that's the bundle rpm we use.

Anybody might find out that they do not like the spacewalk the way it is now, and start reimplementing it. But they might like spacewalk-backend (the .rpm), so they might use it for their common stuff. Why prevent them by putting in Requires that are not technically needed?

Comment 7 Clifford Perry 2008-10-16 19:56:56 UTC
To my knowledge... lots of packages was a legacy of RHN Hosted where only parts of code are wanted to dedicated task systems. Since Spacewalk ships for one physical OS - I suggest merge them all into one single big python/backend package and not split them out anymore. 

Cliff

Comment 8 Jan Pazdziora 2009-01-20 15:10:34 UTC
I've reviewed the situation, and we cannot make spacewalk-backend Require spacewalk-backend* because Proxy only uses spacewalk-backend and does _not_ want the rest.

If Cliff prefers to have those other multiple packages

spacewalk-backend-config-files
spacewalk-backend-app
spacewalk-backend-server
spacewalk-backend-xmlrpc
spacewalk-backend-applet
spacewalk-backend-xml-export-libs
spacewalk-backend-tools
spacewalk-backend-xp
spacewalk-backend-config-files-common
spacewalk-backend-package-push-server
spacewalk-backend-sql
spacewalk-backend-config-files-tool

merged into one, fine, but we will need to keep spacewalk-backend as a different package. So, one possibility is to do the following changes:

spacewalk-backend => spacewalk-backend-commit (it has /usr/share/rhn/common content)
spacewalk-backend-* => spacewalk-backend-server

The question is if we want to do this, if there is enough technical / business / other reason to do it, in Spacewalk 0.5 timeframe.

Cliff?

Comment 9 Jan Pazdziora 2009-01-22 09:59:40 UTC
I propose not to do the dependency thing which started this bugzilla, because of Spacewalk Proxy.

As for possible consolidation of all the non-common backend packages into one, it could be done but I propose to make it Spacewalk 0.6 material.

Do you agree?

Comment 10 Clifford Perry 2009-01-22 14:53:11 UTC
Spacewalk 0.6 - yes. 

I though now have to admit I am in two minds here. The reason being is that if we wanted for Satellite customers (or very large Spacewalk) to allow them to break up their server into physical hardware dedicated to certain tasks - such as 'I am a rhnpush upload server' or 'I *only* serve up /XMLRPC requests from up2date and yum' or 'I only want to use this server for performing inter satellite/spacewalk syncs' - then having a spacewalk-backend-common is good - and then being able to document what specific extra packages are needed to achieve a specific task, makes it easier for folks to disable things that a system is not dedicated too. This reflects back to needing a package structure similar to what we have today. 

So, for now, I say move off Spacewalk 0.5 to 0.6. We should though look to consolidate down from ~13 backend packages to a smaller subset which is more task orientated, would be cool. 

Cliff

Comment 11 Jan Pazdziora 2010-11-19 16:05:35 UTC
Mass-moving to space13.

Comment 12 Miroslav Suchý 2010-11-20 15:14:53 UTC
I do not think that there is too much space to consolidate those sub packages:

Let list what we have:
spacewalk-backend - common libs shared by server and proxy
spacewalk-backend-sql - common database stuff which does not care about database driver
spacewalk-backend-sql-oracle, spacewalk-sql-postgresql - database specific stuff
spacewalk-backend-server - main backend
spacewalk-backend-config-files-common - common code shared by spacewalk-backend-config, spacewalk-backend-config-files-tool.
spacewalk-backend-xmlrpc, spacewalk-backend-applet, spacewalk-backend-xp, spacewalk-backend-iss, spacewalk-backend-iss-export, spacewalk-backend-config, spacewalk-backend-config-files-tool, spacewalk-backend-package-push-server - each package is separate apache handler
spacewalk-backend-libs - code shared by server and client tools (from rhn tools channel)
spacewalk-backend-tools - various tool (including rhn-satellite-exporter and satellite-sync)
spacewalk-backend-xml-export-libs - Libraries required by various exporting tools

I would leave intact all those handlers plus spacewalk-backend-config-files-common, since user may have one machine per handler.
It does not make sense to merge spacewalk-backend-sql, spacewalk-backend-sql-oracle and spacewalk-sql-postgresql.
Additionaly spacewalk-backend and spacewalk-backend-libs are shared with other components so keep it minimal as it is.

So what is left is spacewalk-backend-server, spacewalk-backend-tools and  spacewalk-backend-xml-export-libs. And yes, it seems reasonable to merge this three to one. Most probably to spacewalk-backend-server.

What do you think?

Comment 13 Jan Pazdziora 2010-11-27 17:46:59 UTC
(In reply to comment #12)
> I do not think that there is too much space to consolidate those sub packages:

[...]

Thank you for the investigation.

> So what is left is spacewalk-backend-server, spacewalk-backend-tools and 
> spacewalk-backend-xml-export-libs. And yes, it seems reasonable to merge this
> three to one. Most probably to spacewalk-backend-server.

Well, the fact is that you might not want any exporter installed, yet still have the rest of the backend. So having spacewalk-backend-xml-export-libs might make sense. The same goes for spacewalk-backend-tools.

If those other packages seem like reasonable thing to keep separated, I'd vote to just NOTABUG this.

Please reopen if you disagree.

Thank for once again,

Jan


Note You need to log in before you can comment on or make changes to this bug.