<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Jun 2019 at 08:25, Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 21, 2019 at 7:46 AM Nico Kadel-Garcia <<a href="mailto:nkadel@gmail.com" target="_blank">nkadel@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jun 19, 2019 at 12:32 PM Karanbir Singh <<a href="mailto:kbsingh@centos.org" target="_blank">kbsingh@centos.org</a>> wrote:<br>
> ><br>
> > On 19/06/2019 17:18, Fabian Arrotin wrote:<br>
> > >><br>
> > >> We plan to compose all of those repositories, and deliver updates in the same stream.<br>
> > ><br>
> > > Just so that people realize : no *updates* repo anymore, so all combined<br>
> > > : if you install from network $today, what you'll install $tomorrow will<br>
> > > have all rolled-in directly<br>
> > ><br>
> ><br>
> > that's not going to work - we need to retain the ability to deliver<br>
> > reproducible installs.<br>
> ><br>
> > This may just be a case of having a second set of metadata.<br>
><br>
> A "parent" directory with secondary metadata, including all sub<br>
> repositories, might work if we want it. But I think it's going to<br>
> cause mismatches and confusion between RHEL and CentOS, and we should<br>
> just use the upstream layout. For example, one issue is that the<br>
> upstream channels overlap: the "codebuilder", "highavailability" and<br>
> "resilientstorage" channels have some overlapping SRPMs and RPMs.<br>
> Duplicate content in multiple channels is begging for trouble. The<br>
> activation of modules would seem to compound the problem. Upstream<br>
> filesystems may support filesystems with hardlinks among identical<br>
> RPMs. Installation DVD images will not.<br>
><br>
> > also, what life term are we going to have for the single repo structure<br>
> > ? are we hoping to retain all content for the life of the release ?<br>
><br>
> Good question. I think it's going to be safer to simply perserve the<br>
> upstream layout and enable the additional channels, such as<br>
> "codebuilder" and "highavailability" and "resilientstorage", by<br>
> default. The "ansible" channels may require more thought.<br>
><br>
<br>
I'd rather have this bonkers layout *not* preserved in CentOS. Putting<br>
it all together in one repo (as was done for CentOS 6 and CentOS 7)<br>
has made things tremendously easier. The reason they're broken apart<br>
in RHEL is to allow charging people money for various aspects of RHEL.<br>
Or in the case of the "codebuilder" repo, dumb marketing purposes.<br>
<br>
Simplicity is key here, and having the unified repo makes it *much*<br>
easier to use CentOS and build software from it.<br>
<br></blockquote><div><br></div><div>Due to modularity and compose times etc.. it would make more sense to have at most something like</div><div><br></div><div>Non-modular/</div><div>Modular/</div><div>Updates/</div><div>|------------> Non-modular/</div><div>|------------> Modular/</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
真実はいつも一つ！/ Always, there's only one truth!<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>