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/cd925d940357d145c7106c1c3ed6ed12dff29e9d/client 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