On 10/15/2015 2:10 PM, Matthew Thode wrote:
On 10/15/2015 02:04 PM, Robert Collins wrote:
On 16 October 2015 at 08:01, Matthew Thode <prometheanf...@gentoo.org> wrote:
So, this is my perspective in packing liberty for Gentoo.
We can have multiple versions of a package available to install, because
of this we generally directly translate the valid dependency versions
from requirements.
Cool.
this
oslo.concurrency>=2.3.0 # Apache-2.0
becomes this
>=dev-python/oslo-concurrency-2.3.0[${PYTHON_USEDEP}]
Now what happens when I package something from mitaka (2.7.0 in this
case would be mitaka). It's undefined behaviour as far as I know.
Basically, I can see no reason why the policy of caps changed from kilo
to liberty, it was actually nice to package for liberty, I can see this
going very bad very quick.
They changed because it was causing huge trauma and multiple day long
gate wedges around release times. Covered in detail here -
http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
Where are my caps?
The known good versions of dependencies for liberty are
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/liberty
That's good, does that represent an upper constraint for the lower
constraint imposed by by the package? Why is this kept separate?
Keeping it separate means that it's not trivial to merge them with
what's in each package's requirements.
I'm not sure I understand the first question but I believe that u-c is
automatically adjusted and if there is a conflict with the minimum
version required of a dependency then the cap is adjusted (or vice-versa).
It's separate, at least in part, because the changes to
global-requirements are synced to all projects in the projects.txt file
in the requirements repo, which causes a bunch of churn to get those
changes approved in the registered projects and then released appropriately.
The global sync to the ecosystem isn't fun, I'll agree, but I do think
that thinks have been better since Juno/Kilo because (1) we don't allow
<= caps in g-r anymore (we were not allowing patch version updates which
wedged us several times) and (2) we're better about releasing things
with minor version updates per semver - whereas in the past the cats
were releasing on their own volition and picking the version they
thought was best, which creeped into having multiple versions that could
be acceptable across branches, and we'd have wedges those ways too. I
think a lot of that has been fixed by the openstack/releases repo so
that the cats now have to line up for the release of their library with
a centralized team.
You should be able to trivially pull those versions out and into your
liberty set of packages.
Theres another iteration on this in discussion now, which has to do
with backwards compat *and testing of cap changes*, we'll be in the
backwards compat fishbowl session in Tokyo if you're interested.
-Rob
I'll be at the fishbowl :D
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
