On 10/21/2011 12:54 PM, Johnny Hughes 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-Mieg@xxxxxxx> 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
>
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
And that Johnny has been the answer we have been requesting for a
looooong time now. I figured the upstream packaging changes broke your
systems even when lance said that wasn't the case. The results speak
for themselves. Nothing against the Centos folks you are now being
actively worked against by Redhat itself. This is going to slowly choke
off community builds of RHEL...and force them to fedora. Due to this
decicion byt he upstream is why I'm moving to Ubuntu LTS for my new
servers. It is unfortunate that the abuse by Orcale of the exact
procedure you use that prompted Red Hat to take these packaging measures.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
