Make centos a new distro and forget about rh
2011/11/14 Alan McKay <alan.mckay@xxxxxxxxx>
> 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@xxxxxxxxxx> 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
>
>
> Lamar Owen lowen@xxxxxxxx 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@xxxxxxxxxx
> 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@xxxxxxxxxxxxxxx.<prdc@xxxxxxxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
