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 ? 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 ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190619/2b4edbca/attachment-0008.sig>