[CentOS] Changes at Red Hat confouding CentOS (was: What happened to 6.1)

Tue Nov 15 18:15:04 UTC 2011
Marcio Carneiro <viabsb at gmail.com>

Make centos a new distro and forget about rh

2011/11/14 Alan McKay <alan.mckay at 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 <johnny at 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-Mieg at 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 lowen at 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 to what the consequences of those restrictions might be.
> The RHN AUP simply says that if you redistribute information from RHN
> you lose access to RHN.  It does not restrict your right to
> redistribute anything; it restricts access to future information
> distributions from RHN.  I know that's splitting hairs, but it does
> seem to meet the letter of the license.  After all, RHN access is not
> required except for updates; if I really wanted to do so I could
> redistribute everything I have from RHN at this point in time and
> upstream has no legal recourse against that distribution that I know
> of (but I am neither a lawyer nor a paralegal; Russ on the other hand
> knows of what he speaks....).
> They can, however, choose to not distribute anything else to me in the
> future, and nothing in the GPL or any other license used by upstream
> forces them to distribute anything new to me.  And that's the gestalt
> of the RHN AUP; it states under what conditions RHN will distribute
> the compiled binary code (treated specially by GPL and not as a
> derived work) to you, its customer.  Once you have received the binary
> of a particular version you have the right, under GPL and only for
> GPL-covered packages, to receive the source code for that particular
> version of that package.
> Upstream is very gracious (in my opinion, at least) and distributes
> all of its source, not just GPL source and not just to customers but
> to the public at large (I say all; I haven't personally verified that
> all source in any given RHN channel is indeed available publicly on
> ftp.redhat.com, primarily because I don't have access to all
> channels).  They could distribute only the source that they legally
> have to under those licenses that require it, but not for the source
> covered under other licenses that do not require redistribution of
> source plus modifications.
> But just because I have version 1.2.3 of a package does not give me a
> guaranteed right under GPL to get 1.2.4 from them.  And just because I
> can get the source to the 1.2.4 package they distribute does not give
> me an automatic right to the corresponding binary as the GPL does
> treat the compiled code specially.  If you get the binary, you have
> the right to the source; if you have the source it is assumed you can
> generate the binary yourself (as is proven by the various EL
> rebuilds).
> The level of difficulty required to generate the binary is not
> specified or even addressed by the GPL, nor does the GPL guarantee
> your ability to generate the exact same binary as someone else
> distributes..... nor is the distributor of the binary restricted at
> all in how difficult generating their exact binary, or a 100%
> compatible binary, can be.  This seems to be the current holdup with
> C6.1, in my opinion; you can build *a* binary but will it work just
> like *the* binary?  Upstream can make it even more difficult than they
> already have (and I know it's currently very frustrating to the CentOS
> team just from reading this thread!).
> Russ, is that summary even close to accurate in your opinion?
> These are the facts of life for an EL rebuild distribution user.  If
> you want a primary access distribution (rather than a secondary
> rebuild) you need to find one that meets your needs, either by paying
> up for upstream or by going to something else (and there are really
> only two suitable enterprise choices for 'something else' in this case
> (and in my opinion): OpenSuSE or Debian Stable).
>  I'm evaluating Debian Stable on IA64 myself, as Debian Stable is the
> only actively maintained enterprise-grade distribution (again, in my
> opinion) freely available for IA64 (yes, upstream's EL5 is still
> available and is still maintained, but it costs six arms and eight
> legs to purchase for the machines I have; SLES likewise).
> And I don't really currently have the time to rebuild C6 for IA64
> myself.  I'd love to, and I've had conversations with like-minded
> people, and I don't really want to go to Debian on it since I really
> want the IA64 boxes to work like all the other servers here which are
> running upstream EL rebuilds.  But I have more important and necessary
> things to do with my time at the moment than to get into the game of
> maintaining a private rebuild for IA64 (I say private; even if I had
> time to maintain the build I don't have time to deal with the 'issues'
> of a public build!).
> --
> “Don't eat anything you've ever seen advertised on TV”
>          - Michael Pollan, author of "In Defense of Food"
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

Analista de Sistemas
*MBA em Logística:<http://www.logisticadescomplicada.com/a-auto-regulacao-dos-servicos-de-transporte-publico-urbano-de-passageiros/>Gerência
Executiva de Transportes, Mobilização e Meio Ambiente - GETRAM
Provedor <http://www.InstitutoFederalista.com/debate/> de Serviços na

Atenção: Esta carta pode conter anexos no formato *ODF* (*Open Document
Format*)/*ABNT* (extensões *odt*, *ods*, *odp*, *odb*, *odg*). Antes de
pedir os anexos em outro formato, você pode instalar gratuita e livremente
o *LibreOffice* <http://www.libreoffice.org/download> ou o seguinte Aditivo
para Microsoft Office (R) (

Converse na rede em:


(senha: *federalistas**)*

O GMail não permite que você retire sua correspondência do servidores da


para o *Ministério Público Federal* em
prdc at prdf.mpf.gov.br.<prdc at prdf.mpf.gov.br>