
<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Jun 19, 2019, at 13:25, Karanbir Singh wrote:<br></div><blockquote type="cite" id="qt"><div>On 19/06/2019 19:22, Brian Stinson wrote:<br></div><div>> <br></div><div>> On Wed, Jun 19, 2019, at 13:07, Karanbir Singh wrote:<br></div><div>>> On 19/06/2019 17:45, Brian Stinson wrote:<br></div><div>>> > <br></div><div>>> > On Wed, Jun 19, 2019, at 11:32, Karanbir Singh wrote:<br></div><div>>> >> On 19/06/2019 17:18, Fabian Arrotin wrote:<br></div><div>>> >> >><br></div><div>>> >> >> We plan to compose all of those repositories, and deliver updates<br></div><div>>> >> in the same stream. <br></div><div>>> >> > <br></div><div>>> >> > Just so that people realize : no *updates* repo anymore, so all<br></div><div>>> combined<br></div><div>>> >> > : if you install from network $today, what you'll install<br></div><div>>> $tomorrow will<br></div><div>>> >> > have all rolled-in directly<br></div><div>>> >> > <br></div><div>>> >><br></div><div>>> >> that's not going to work - we need to retain the ability to deliver<br></div><div>>> >> reproducible installs.<br></div><div>>> > <br></div><div>>> > Can you clarify this? What "reproducible install" pattern is broken<br></div><div>>> here?<br></div><div>>> > <br></div><div>>> >><br></div><div>>><br></div><div>>> I need to be able to run installs against a mirror, weeks and months<br></div><div>>> apart and arrive at the same payload installed exactly.<br></div><div>>><br></div><div>>> regards<br></div><div>> <br></div><div>> Is there something preventing you from doing that if we ship updates in<br></div><div>> the same repo as the 0-day release content?<br></div><div>> <br></div><div><br></div><div>yes,<br></div><div><br></div><div>if i yum install <httpd>; with the base only. I'd like to get the same<br></div><div>httpd, not the 3 versions removed in the updates that have now landed in<br></div><div>the same repo.<br></div><div><br></div><div>again, this maybe just a case of publishing a 2nd set of metadata rather<br></div><div>than retain the base rpm set, but we need to retain this functionality.<br></div><div><br></div></blockquote><div><br></div><div>Wouldn't pinning versions be better here if that's what you need? If you took that same kickstart over to a RHEL machine, you'd get the updates over there. <br></div><div><br></div><div>Seems to me like delivering the updates separately goes against our community recommendations anyways (i.e. the first thing we say in irc is "did you run yum/dnf update?"). <br></div></body></html>