[CentOS-devel] Why are Spacewalk packages removed from CentOS?

On Mon, 15 Feb 2010, Marcus Moeller wrote:

> Dear Dag.
>
>> I don't understand. Without the (upstream) RHEL RHN client in CentOS
>> people are forced to use another repository, even when the RHN client
>> would be sufficient.
>
> One disadvantage of using RHN(S) to manage CentOS machines is that you
> cannot really manage EPEL with it as it contains some 'duplicate'
> packages which are already in the Red Hat Tools channel.

You can disable a channel when using activation keys, much as with 
Spacewalk I would assume. You can also populate channels in an automated 
fashion. Both with RHN and Spacewalk.


>> Sure there are benefits, if you'd be interested to use CentOS with the
>> corporate RHN Satellite (to keep RHEL+CentOS infrastructure identical). Or
>> simply to bootstrap from RHN/Spacewalk to download/install the updated
>> spacewalk client ?
>>
>> Why not ?
>
> If the packages are going to be incompatible one time, you cannot even
> register your system to Spacewalk.

With an emphasis on *if*.

And the same will be true for RHEL. So when we make CentOS different from 
RHEL, the documentation for both may become different in that area. Is 
that what we really want ?

Also if CentOS would become identical to RHEL, it may change the dynamics 
and reasoning for (preventing) incompatibility changes. So I think there's 
a good reason for keeping things compatible. Whether people want to use 
RHEL/CentOS with RHN Satellite or using RHEL/CentOS with Spacewalk.

We can not base decisions on things that may or may not happen in the 
future. In fact, keeping things identical to RHEL protects us from 
changes that will happen in the future. Nobody can blame us for being 
identical to RHEL.

People may blame us for deviating from RHEL, which is what we will keep on 
doing if we leave the RHN libraries/client out.

Although I don't think I will be changing your mind, Marcus, because for 
your use-case there is no benefit.

Kind regards,
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]