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-0008.html>