Hello list,
I am trying to build the rhn-client-tools package for a Debian client.
In this mail I try to collect my thoughts and facts.
Problems:
(A) A big part of the code depends directly on python-rpm.
We don't want 'import rpm' on Debian nor 'import apt' on Fedora.
(B) /etc/sysconfig does not exist on Debian
(C) redhat-release does not exist on Debian
(D) Architecture names are slightly different
Potential solutions:
(1) Create a Debian patch, and apply it only when building the .deb
package. It is easier for start, but the patch needs to be maintained.
(2) Modify upstream rhn-client-tools, to include bits for both: Debian &
Fedora and choose one during a build-time.
(3) Same as (2) but in run-time. (polymorphism).
(4) interleave with if-else:
if getPlatform() == 'deb': import apt
else: import rpm
(5) Still there is an option to write rhn-client-tools from scratch.
(Design new interface). I doubt anybody likes that.
---
I have already started with the (3) option. The reason I am writing this
mail is that my result does not seem much promising.
The third option assumes a lot of refactoring and it's not elementary.
For instance each module containing 'import rpm', could be extracted to
3 or 4 submodules:
- one top level
- to preserve current interface
- containing platform independent functions
- doing the magic to import either deb or rpm variant
- one for rpm dependent functions
- one for deb dependent functions
As you can see, it's not acceptable. Application logic will be lost in
the pile of modules.
In the opposite way, creating a single module for Debian and another for
Fedora, would result in a big inconsistent modules.
Unless you have better idea, I'll start with (1) option.
--
Simon Lukasik
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
