On Fri, Jun 21, 2019, at 07:25, Neal Gompa wrote:
On Fri, Jun 21, 2019 at 7:46 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Jun 19, 2019 at 12:32 PM Karanbir Singh kbsingh@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@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.