Dear all,
After filing a bug (http://bugs.centos.org/view.php?id=4315) Karan made me aware of a discussion held in January 2010. There was no conclusion, no decision.
The origin was from Miroslav he was requesting to include rhnlib and friends as I made is on the bug report, and I totally agree with him.
Let me pick up the pros and cons discussed in January:
Quoting Miroslav @ http://lists.centos.org/pipermail/centos-devel/2010-January/005319.html
<quote> Partialy true. Recent upstream version will not hit accidentaly rhn.redhat.com That version included in RHEL will do that by default. But these change: https://fedorahosted.org/spacewalk/changeset/cd925d940357d145c7106c1c3ed6ed1... is only one which are required to prevent from accidental check of rhn.redhat.com
So my recomendation is: take this patch and apply it on current rhel5 package and include all of them in CentOS. </quote>
As I stated, I agree with Miroslav, the only thing we need to care is not to bother people with "click-trough-installations" with "install-numbers" and stuff (This is in anaconda, right?)
Lets have a look at http://lists.centos.org/pipermail/centos-devel/2010-January/005321.html
Quoting Marcus: <quote> Spacewalk development is much faster which may lead into missing features as they are not yet implemented in the version that is meant to be used with rhn. </quote>
From my point of view this does not matter that much.I was able to register a RHEL 5.4 to a spacewalk server (0.8? Dont remember, it was just for the sake, not for production). Since spacewalk is the upstream of the RHN satellite, Red Hat will be careful to break API compatibility between rhn-client and RHN Satellite/Spacewalk. Recently I replaced a RHN Sat 5.0 with 5.3. (AFAIR the base of 5.3 was spacewalk 0.5). The only thing that changed from the client side was the activation key.
There also have been a change for RHEL5.5 and sat 5.3 (too lazy to search for the errata). The yum errata was published weeks before RHEL5.5 hits the street.
@Miroslav and the other RHN Sat/Spacewalk developers: Can you promise to announce incompatible changes early enough? If yes, CentOS can include the stuff immediately.
Quoting Karan @ http://lists.centos.org/pipermail/centos-devel/2010-January/005361.html
<quote> A very large number of pople who use centos, do so with little or no previous understand of linux or even the basics of systems management - we need to keep those people in mind as well. The problem that we have had, in the past, is that installing yum-rhn-plugin brought in loads of rhn* packages as well, which in turn would cause traffic to rhn.r.c. Also, given that rhn itself is a rhel connected service, the view we took was that there is no need for that functionality in the distro at all. </quote>
This is partially true. Another fact about CentOS is IMHO, that a lot of people and companies are using CentOS as a testbed for RHEL. I guess that even more users of spacewalk are using it a a replacement for a RHN sat, since RH does only provide 30 days test licences for RHN sat.
Companies have (more or less) large test-environments with CentOS. For those companies it would be a great benefit to have those packages in stock CentOS.
Benefits for my self: My daily work is with RHEL and RHN Satellite. In meanwhile I have quite a good to excellent knowledge of RHN sat and its future (I'm a git reader). This is mainly due to the existence of spacewalk. At the moment implementing a complete testbed consisting of CentOS AND spacewalk means quite a lot of work, due to to missing rhnlibs and friends in CentOS.
Conclusion: With a very small patch as Miroslav suggested to avoid bothering rhn.redhat.com we can have a OS with is attracting to more people.
If I can help maintaining the stuff, let me know, I'll do my best....
Thanks,
Luc
On 05/17/2010 10:53 PM, Luc de Louw wrote:
Dear all,
After filing a bug (http://bugs.centos.org/view.php?id=4315) Karan made me aware of a discussion held in January 2010. There was no conclusion, no decision.
IIRC there *was* conclusion. For CentOS 5.x keep status quo and do not change anything. And for CentOS 6.0 (when it will be ready) keep those package in CentOS (or in other words, do not remove them when picking up packages from RHEL).
@Miroslav and the other RHN Sat/Spacewalk developers: Can you promise to announce incompatible changes early enough? If yes, CentOS can include the stuff immediately.
Packages in RHEL will be *always* backward and forward compatible. We are not promising the same for Fedora, but for RHEL yes.
Benefits for my self: My daily work is with RHEL and RHN Satellite. In meanwhile I have quite a good to excellent knowledge of RHN sat and its future (I'm a git reader). This is mainly due to the existence of spacewalk. At the moment implementing a complete testbed consisting of CentOS AND spacewalk means quite a lot of work, due to to missing rhnlibs and friends in CentOS.
That was my understanding. But I'm "just" developer. And I understand that for every distribution should be Vox Populi, Vox Dei. So if more CentOS users requests those packages for CentOS 5.6, then CentOS developers may change their mind. But I will not be (and could not be) the one who will agitate for it.
Hi all.
@Luc, I have not noticed you on any Spacewalk discussions before and from what you have written, I guess you have not (yet) fully understood how Spacewalk works.
If you provision from Spacewalk (and that's what it's meant to be for), you can simply 'attach' the Spacewalk tools channel during installation which will make the necessary tools available.
After filing a bug (http://bugs.centos.org/view.php?id=4315) Karan made me aware of a discussion held in January 2010. There was no conclusion, no decision.
IIRC there *was* conclusion. For CentOS 5.x keep status quo and do not change anything. And for CentOS 6.0 (when it will be ready) keep those package in CentOS (or in other words, do not remove them when picking up packages from RHEL).
The major concern I had was that this would lead to multiple packages with different versions, as the 'CentOS' client tools will then be the ones from RHEL and the Spacewalk tools channel will contain the updated ones. (I had a few other concerns but I am not going to repeat them)
The only option I see (besides keeping things as they are, which is the best imho) is to include ALL the latest Spacewalk client tools in CentOS (which will perhaps break binary compatibility but could be OK). This would obsolete the need of a dedicated Spacewalk tools repository, too (we have to talk to the SL guys if we would like to do so).
Russ once complained that this might break the possibility to register CentOS against Satellite, but this will never be a good and working solution for CentOS imho (Here also, if you don't know why, please compare features and workflow of both products).
The next thing we have to be aware of, then would be EPEL compatibility
@Miroslav and the other RHN Sat/Spacewalk developers: Can you promise to announce incompatible changes early enough? If yes, CentOS can include the stuff immediately.
Packages in RHEL will be *always* backward and forward compatible. We are not promising the same for Fedora, but for RHEL yes.
So why are there different client tools channels per Spacewalk version, then (which is only one on Statellite btw.)?
Best Regards Marcus
-
Luc de Louw -
Marcus Moeller -
Miroslav Suchý