[openstack-dev] [requirements] [packaging] How can Upper Constraints be used by packagers

Doug Hellmann doug at doughellmann.com
Thu May 12 16:56:57 UTC 2016

Excerpts from Matthew Thode's message of 2016-05-12 11:01:52 -0500:
> On 05/12/2016 09:57 AM, Igor Yozhikov wrote:
> > 
> > Hello.
> > 
> > According to proposed changes in G-R
> > (https://etherpad.openstack.org/p/newton-global-requirements)  related
> > to ranges/bounds I want to clarify situation for Linux packagers.
> > 
> > Very often packages for requirements mentioned in requirements.txt or
> > global-requirements  file are built using code versions set in lower
> > bounds. Usage of broader range for requirements will lead to complex
> > calculations of minimum version of requirement which will satisfy all of
> > projects which are using it. From perspective of packaging - must be
> > only one installed version of requirement in a system.
> > 
> > To avoid this complexity and provide co-installability, upper
> > constraints could be used as the source of minimal version for
> > requirements in system package.
> > 
> Hi, Gentoo packager here :D
> The basic gist of it is that g-r.txt is what's expected to work and
> u-c.txt is what's tested to work.  There have been specs out there to
> test a lower-contraints.txt file but I haven't seen it go anywhere quite
> yet.

As Matthew said, the upper constraints list is the set of things we're
actively testing and the range in the global requirements list is the
things we believe to work. We have both to give distros some flexibility
in what they actually package.  That said, I heard pretty consistently
from distro folks at the summit that they try to package the most current
versions of all dependencies. That's more or less what we're testing
with the upper constraints in place, except for the cases where we know
an update breaks something.


More information about the OpenStack-dev mailing list