[CentOS-devel] RFC: CentOS 8 Repository Structure

[Brian Stinson]

On Wed, Jun 19, 2019, at 13:10, Karanbir Singh wrote:
> On 19/06/2019 18:47, Stephen John Smoogen wrote:
> > 
> > 
> > On Wed, 19 Jun 2019 at 12:32, Karanbir Singh <kbsingh at centos.org
> > <mailto: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.
> > 
> > 
> > I think there is some confusion as what Brian is describing is what RHEL
> > has been doing since EL6.
> > 
> > This isn't any different from what RHEL does now. You have a primary iso
> > image you instal from but if you point a kickstart to a
> > baseurl=https://cdn.<foo> you get whatever was in the compose of the day
> > (with all the previous packages there also but most installs will just
> > pull the latest). If you want a reproducible RHEL install you need to
> > only use the ISO or some similar frozen toolkit (Satellite, specific
> > local branches, etc) but otherwise you can get different installs each
> > day. Whether this is a good design or not is a different question... but
> > it is one which has been in place for nearly 10 years in the RHEL
> > upstream. [Currently the Fedora up-upstream does keep /updates/ but that
> > is done by other production tools.]
> 
> unsure how/what you are talking about here - are you saying that we are
> going to adopt the RHEL delivery model ? if so, how are z stream going
> to work ? are we doing mappings for those as well now ?

Very much not in favor of doing z-stream updates. But EUS is a separate RHEL entitlement, does the existence of EUS somehow change the discussion here? 

> 
> additionally, the subs manager allows me to lock out and away specific
> rhel content, on a rhel machine - are we adopting that as well ?
> 
> 
> >
> > This may just be a case of having a second set of metadata.
> > 
> > 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 ?
> > 
> > 
> > I believe what Brian was saying is that this would only be retained for
> > the life of a point release, but I may be misunderstanding. 
> > 
> 
> That works, can we get confirmation here ?

I deliberately left that unspecified to generate discussion here. The tradeoff is between keeping large amounts of history, and conserving space on the mirrors. If we want to prune at point-release time we can. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190619/c5878ee9/attachment.html>