[CentOS-devel] RFC: CentOS 8 Repository Structure

Wed Jun 19 18:10:48 UTC 2019
Karanbir Singh <kbsingh at centos.org>

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>