On Friday, September 23, 2011 12:57:31 PM Johnny Hughes wrote: > There is a whole channel of RPMs that we are not allowed to look at from > upstream now. They do not release them on any ISOs and we can't pull > things directly off RHN (the only way to get the optional channel) and > use it. This is just one of many issues we are having right now. Just for clarification, this is to check binary compatibility, correct? The source RPM's are in the regular location on the ftp.redhat.com site, at least the few I looked at in the optional channel are. I think many here simply do not understand the degree of meticulousness required to check binary compatibility at the level the CentOS team has historically checked binary compatibility. To the best of my knowledge, checking binary compatibility requires having a copy of the target binary package from a subscribed system (ideally, you'd likely want to do the checking, or generating a compatability 'signature' of some sort, on a subscribed system to prevent running afoul of the subscription terms of service). To do this for all channels requires multiple licensed and subscribed systems, as far as I can tell from looking at the set of packages I see from my duly subscribed RHEL 6.1 box (duly as in I have paid for the subscription). But I reserve the right to be wrong. RHEL 6.1 also made significant anaconda installer improvements; to do a full-up 6.1 requires dealing with that, too. The current setup upstream that I can see appears to have made things drastically more difficult, at least from my point of view. And the intended targets weren't CentOS and SL; rather, other commercial competitors providing their own support were the intended targets, IMHO. While I have asked myself this question (and I think I have it answered privately to my own satisfaction), I really don't think it's appropriate in this list to ask 'well, why has SL been able to release a 6.1 if it is so hard?' since the two projects are different and have different goals, different infrastructure (particularly on the build side), and different teams; no, I'm not going to share my own private answer with anyone, don't even ask. Suffice to say that I will have some SL boxes, and I'll continue to have some CentOS boxes, and I have an RHEL box in my most critical point, and will use each distribution in the role(s) it is most suited to as appropriate to the resources available to support those roles.