Make centos a new distro and forget about rh
2011/11/14 Alan McKay alan.mc...@gmail.com
These seems to me to be the first message in the series and provides a
really good summary of the changes at Red Hat which seem to be making
life a lot more difficult for CentOS.
Just figured I'd pull it out of that thread and change the subject line.
Below Johnny's email I've copied another from the original thread,
written by Lamar Owen, which gives some good explanation on how Red
Hat is able to get away with this.
Basically from what I gather, while Red Hat cannot restrict access to
sources, they can restrict access to binaries. And since CentOS has a
goal of binary compatibility with upstream, they are essentially left
trying to hit an unknown target. But (now I'm stretching my limited
knowledge even further) Scientific does not have this restriction
since they are less concerned about exact binary compat.
On Fri, Oct 21, 2011 at 12:54 PM, Johnny Hughes joh...@centos.org wrote:
On 10/21/2011 10:01 AM, Les Mikesell wrote:
On Fri, Oct 21, 2011 at 9:51 AM, Nicolas Thierry-Mieg
nicolas.thierry-m...@imag.fr wrote:
Johnny, chill. I don't blame him for being confused. Up until right
now,
you updated to a point release, then, over the weeks and months, there
were updates. All of a sudden, there are *no* updates for the 6.0
point
release, which is a major change in what everyone expected, based on
history.
this is the way it has always been: once upstream releases x.y+1 ,
there
are no more updates to x.y (in upstream and therefore also in centos),
until centos releases x.y+1 .
Yes, but that used to be transparent, because the centos x.y+1 release
happened quickly so it didn't matter that the update repo was held
back until an iso build was done.
Yes, and NOW the release process is MUCH harder.
Red Hat used to have an AS release that contained everything ... we
build that and we get everything. Nice and simple. Build all the
packages, look at it against the AS iso set ... done. Two weeks was
about as long as it took.
Now, for version 6, they have:
Red Hat Enterprise Linux Server (v. 6)
Red Hat Enterprise Linux Workstation (v. 6)
Red Hat Enterprise Linux Desktop (v. 6)
Red Hat Enterprise Linux HPC Node (v. 6)
Red Hat Enterprise Linux Workstation FasTrack (v. 6)
Red Hat Enterprise Linux Server FasTrack (v. 6)
Red Hat Enterprise Linux Desktop FasTrack (v. 6)
Red Hat Enterprise Linux Scalable File System (v. 6)
Red Hat Enterprise Linux Resilient Storage (v. 6)
Red Hat Enterprise Linux Load Balancer (v. 6)
Red Hat Enterprise Linux HPC Node FasTrack (v. 6)
Red Hat Enterprise Linux High Performance Network (v. 6)
Red Hat Enterprise Virtualization
They have the same install groups with different packages based on the
above groupings, so we have to do some kind of custom generation of the
comps files to things work.
They have created an optional channel in several of those groupings that
is only accessible via RHN and they do not put those RPMS on any ISOs
... and they have completely changed their Authorized Use Policy so
that we can NOT login to RHN and use anything that is not on a public
FTP server or on an ISO set ... effectively cutting us off from the
ability to check anything on the optional channel.
Now we have to engineer a compilation of all those groupings, we have to
figure out what parts of the optional channels go at the point release
and which ones do not (the ones that are upgrades). Sometimes the only
way to tell is when something does not build correctly and you have
reverse an optional package to a previous version for the build, etc.
We have to use anaconda to build our ISOs and upstream is using
something else to build theirs .. so anaconda NEVER works anymore out
of the box. We get ISOs (or usb images) that do not work and have to
basically redesign anaconda.
We can't look at upstream build logs, we can't get all the binary RPMs
for testing and be within the Terms of Service.
And with the new release, it seems that they have purposely broken the
rpmmacros, and do not care to fix it:
https://bugzilla.redhat.com/show_bug.cgi?id=743229
So, trust me, it is MUCH more complicated now than it was with previous
releases to build.
With the 5.7 release, there were several SRPMS that did not make it to
the public FTP server without much prompting from us. And with the
Authorized Use Policy, I can not just go to RHN and grab that SRPM and
use it. If it is not public, we can no longer release it.
So, the short answer is, it now takes longer.
Thanks,
Johnny Hughes
Lamar Owen lo...@pari.edu via centos.org
Oct 28
to CentOS
On Friday, October 21, 2011 02:22:26 PM Les Mikesell wrote:
Which is explicitly imposing additional restrictions. Which is
explicitly prohibited in section 6. I don't see any exceptions
relating
