[openstack-dev] [packaging] liberty doesn't have caps on deps

Matthew Thode mthode at mthode.org
Thu Oct 15 19:35:08 UTC 2015


On 10/15/2015 02:17 PM, Matt Riedemann wrote:
> 
> 
> 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
>>> <prometheanfire at 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.
> 

I'd agree with this, I still don't know what to cap things to.  I need
to figure out what the caps should be...  It could be hard to sync
across projects but like you say, most of that's gotten better since then.

>>
>>> 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
>>
> 

Anyone have a sched link to that fishbowl, I can't find it :(

-- 
Matthew Thode



More information about the OpenStack-dev mailing list