On 04/19/2016 11:48 AM, Thierry Carrez wrote: >> Remember that in distros, there's only a single version of a library at >> any given time, at the exception of transitions (yes, in Red Hat it's >> technically possible to install multiple versions, but the policy >> strongly advocates against this). > > Depends on the distro. Gentoo for example lets you have multiple > versions of libraries installed at any given time.
Earlier, I wrote that Gentoo was probably an exception, but reading posts from Matthew Thode, he explained that it wasn't really a good idea even in Gentoo to bundle libs. So let's consider that's not an option for all distros packaging OpenStack. > I expect in the future the one-version-of-lib-at-a-time > will more and more be seen as a self-imposed limitation It has always been the case that it's a self-imposed limitation, because that's the only sane way to maintain software. > and less as a > distribution axiom, and next-generation distros will appear that will > solve that limitation one way or another. I very much doubt that distribution will attempt shooting themselves in the foot, and allow software to use deprecated, old versions of libs, which conflict with each other. What can be done is mitigate issues, at most. I fail to see how hiding the issue that 2 libs are conflicting, or that component A can't support the latest version of component B can be seen as the "next-generation" thing that solves all troubles. I'm very much concerned that we're here, taking the same wrong approach of thinking that containing libs and avoid conflict will solve troubles. That's not the case, it just hides it. We still need to make sure that components will support the last versions of everything at the release time, otherwise, we'll have serious issues maintaining stable branches. If the problems is just releasing a lot of work from the release team (and infra, as you just pointed, TTX), then I have given a list of things we could do. These things wont IMO impact quality, and will still allow co-instability. I'll attempt to list it again, in a more clear way: 1- stopping to propagate the global-requirements.txt versions *of OpenStack components* to each and every project: this isn't helping anyone anyway, since both the gate and downstream distros are going to use the latest version. Example: Let every component decided what is the minimum version of oslo.utils that it needs, but still force it to support the latest upper-constraints.txt version. 2- stop maintaining requirements for modules which are only needed by a single project. Simply listing it (to make sure we don't have a 2nd component that adopts it without knowing about the first) will be enough, and this could be done in a separate file, which would point at the project. Example: Take PuLP out of global-requirements.txt, and move it to "used-by.txt" (the name of that file can be something else): echo "PuLP: congress" >>used-by.txt Then let Congress decide what version it needs. I'm not sure yet about the consequences for 3rd party libs, this will probably require more thinking and brainstorming, but right now, it's my strong believe that we still need to maintain key packages in the global-requirements.txt (I'm thinking about Alembic, SQLA and such). Would the above releasing a lot of work from both infra and release teams? Is this "enough", or would there still be too much work? Maybe we could give this new workflow a try for a cycle, and see how it works out? Please, voice your concerns, share your view, etc. Hoping the above is constructive enough, Cheers, Thomas Goirand (zigo) __________________________________________________________________________ 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