<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 July 2015 at 16:59, Ian Cordasco <span dir="ltr"><<a href="mailto:ian.cordasco@rackspace.com" target="_blank">ian.cordasco@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>So, I'm not proposing that yaprt be updated to forcibly add epochs or<br>
anything else. What yaprt will generate is exactly what upstream<br>
specifies. For example, glance would be version 11.0.0, nova would be<br>
12.0.0, etc.<br>
<br>
Giving a more concrete example (which I should have done in the original<br>
message):<br>
<br>
If we're upgrading Glance in the containers, we'll be upgrading from<br>
<br>
glance==2015.1.0 (obviously not exactly that, but for the sake of this<br>
example bear with me)<br>
<br>
To<br>
<br>
glance==11.0.0<br>
<br>
And we'll use the version that yaprt reports to do<br>
<br>
# pip install glance==11.0.0<br>
<br>
So the repositories that we build can have both 2015.1.0 and 11.0.0 in it<br>
and pip will always install 11.0.0.<br>
<br>
This allows for<br>
<br>
1. In-place upgrades<br>
2. Reproducibility<br>
3. Stability<br>
4. Side-stepping upstream refusing to use epochs<br></blockquote><div><br></div><div>Perfect, this is exactly what I was hoping for.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does that make sense?<br></blockquote><div><br></div><div>Perfectly. +1 from me on the approach. </div></div>
</div></div>