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 InterNet 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) ( http://www.sun.com/software/star/odf_plugin/get.jsp). Converse na rede em: http://iso27000.speeqe.com/ http:/Federalistas.speeqe.com/<http://iso27000.speeqe.com/> http://onsync.digitalsamba.com/go/viabsb/federalistas (senha: *federalistas**)* O GMail não permite que você retire sua correspondência do servidores da empresa, *IMPEDINDO AO CIDADÃO LIVRE ACESSO À SUA PRÓPRIA CORRESPONDÊNCIA*! DENUNCIE para o *Ministério Público Federal* em prdc at prdf.mpf.gov.br.<prdc at prdf.mpf.gov.br>