On Fri, Jun 21, 2019, at 07:25, Neal Gompa wrote: > On Fri, Jun 21, 2019 at 7:46 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote: > > > > On Wed, Jun 19, 2019 at 12:32 PM Karanbir Singh <kbsingh at centos.org> wrote: > > > > > > On 19/06/2019 17:18, Fabian Arrotin wrote: > > > >> > > > >> We plan to compose all of those repositories, and deliver updates in the same stream. > > > > > > > > Just so that people realize : no *updates* repo anymore, so all combined > > > > : if you install from network $today, what you'll install $tomorrow will > > > > have all rolled-in directly > > > > > > > > > > that's not going to work - we need to retain the ability to deliver > > > reproducible installs. > > > > > > This may just be a case of having a second set of metadata. > > > > A "parent" directory with secondary metadata, including all sub > > repositories, might work if we want it. But I think it's going to > > cause mismatches and confusion between RHEL and CentOS, and we should > > just use the upstream layout. For example, one issue is that the > > upstream channels overlap: the "codebuilder", "highavailability" and > > "resilientstorage" channels have some overlapping SRPMs and RPMs. > > Duplicate content in multiple channels is begging for trouble. The > > activation of modules would seem to compound the problem. Upstream > > filesystems may support filesystems with hardlinks among identical > > RPMs. Installation DVD images will not. > > > > > also, what life term are we going to have for the single repo structure > > > ? are we hoping to retain all content for the life of the release ? > > > > Good question. I think it's going to be safer to simply perserve the > > upstream layout and enable the additional channels, such as > > "codebuilder" and "highavailability" and "resilientstorage", by > > default. The "ansible" channels may require more thought. > > > > I'd rather have this bonkers layout *not* preserved in CentOS. Putting > it all together in one repo (as was done for CentOS 6 and CentOS 7) > has made things tremendously easier. The reason they're broken apart > in RHEL is to allow charging people money for various aspects of RHEL. > Or in the case of the "codebuilder" repo, dumb marketing purposes. > > Simplicity is key here, and having the unified repo makes it *much* > easier to use CentOS and build software from it. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > To be clear, the plan is to *not* ship separate repositories for ResilientStorage, NFV, HighAvailability, or RT. There may be components of those upstream channels that make it into BaseOS.