Hello Matthew, I use the following for my channels.
centos-production-v6-64bit-base = CentOS OS repo centos-production-v6-64bit-updates (child of centos-production-v6-64bit-base) = CentOS Updates repo centos-production-v6-64bit-extras (child of centos-production-v6-64bit-base) = CentOS Extras repo spacewalk-client-v6-64bit (child of centos-production-v6-64bit-base) = Spacewalk Client repo. This configuration allows me to have the current version of CentOS that is released as I use the url http://mirror.centos.org/centos/6/ and not http://mirror.centos.org/centos/6.3/ as this allows me to update to major revisions quickly without having to change anything. I have not tried two repositories connected to one channel but I think it might work. I feel using the base channel for the OS and updates channel as a child channel allow me more control over the packages that get installed on my systems and keeps separation of the packages in their perspective channels/repos. Basically I just mirrored what a client configuration would look like on a system using yum. When you run a yum command you can see what channels are subscribed and be able to troubleshoot which channel is having issues. You will also be able to exclude packages based on the channel as with one channel for all repositories you wouldn't be able to exclude say kernel from updates as the config you would have to setup would exclude kernel from all repos as it is only one channel. On Tue, Sep 4, 2012 at 3:46 PM, Matthew Patton <mpat...@inforelay.com>wrote: > I can readily imagine the converse; a single repository being a component > of many channels. But (potentially) different repos being part of the same > channel? > > Or am I think about Channels all wrong? Should I just define say a > "centos6" channel and associate the 'base', 'update', 'extras', 'contrib', > 'spacewalk client' repositories to it? I've never seen that in real life or > in an example. They've always been broken out into individual channels and > made into a hierarchy of channels. > > -- > Cloud Services Architect, Senior System Administrator > InfoRelay Online Systems (www.inforelay.com) > > ______________________________**_________________ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/**mailman/listinfo/spacewalk-**list<https://www.redhat.com/mailman/listinfo/spacewalk-list> >
_______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list
