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. > > regards, > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel