[PKG-Openstack-devel] Re-aligning the OpenStack dependency chain across Ubuntu/Debian

[Thomas Goirand]

On 06/05/2015 11:45 AM, James Page wrote:
> Hi Folks
> 
> I've spent quite a bit of time this week working on re-aligning the
> dependency chain for OpenStack packages across Ubuntu/Debian.
> 
> The target of this work is for OpenStack Liberty, so all uploads have
> been targeted to experimental, rather than unstable where Thomas is
> focussed on Kilo still.
> 
> The current status is that most of the Oslo packages are either a) in
> the NEW review queue for FTP master review (either new transitional
> packages for Ubuntu oslo-XXX naming or source package renames to
> python-oslo.XXXX) or b) committed to debian/liberty branches in the
> Debian git repositories awaiting release and upload due to
> dependencies on a).
> 
> I'll continue to work on that next week, as soon as the first batch of
> updates gets through the NEW queue and into the experimental archive.
> 
> I have of course being testing the new packaging on Ubuntu as well:
> t
>  https://launchpad.net/~james-page/+archive/ubuntu/debian-convergence

Thanks a lot for this work, James.

I'd like to work on the core packages to try to realign them with
Ubuntu. This can be done in the Liberty branch before Liberty beta 1 is
released. As you know, the Debconf is a contencious issue. I see 2 ways
to fix that:

1/ Add a first screen asking the user "do you wish to have debconf
handling of your configuration file", which would be set to no by
default. We can, in the postinst, save this value into
/etc/openstack/<project-name> (as it's the policy this value must be
saved somewhere).

2/ Make it so that all of the debconf stuff gets removed on some
condition when building the package. For example, it could be an
environment variable, or "dpkg-vendor --derive-from ubuntu", or even
both (with the environment variable having priority).

I don't see any other ways to handle the differences. If you have other
ideas, let me know.

Then, I would strongly have a preference for solution 1/. If that one
isn't an option for you, let me know and I will start implementing 2/.

Once we agree on this technical decision, then I can start merging
packages with less controversy, like Ceilometer, Cinder, or Keystone.
I'll try to take the best of both worlds, with the (build-)dependency
versions targeting both Jessie and Trusty. For example, even in the
Jessie package, we would see "python-netaddr (>= 0.7.12)", even though
we have that version in Debian stable, and because Trusty only has 0.7.10.

I currently have a tool called "pkgos-reqsdiff" which tries to find the
version of a given package in Jessie, using madison-lite. My idea is to
use madison-lite to see which version is the lowest between Jessie and
Trusty, and use that version as a base to calculate what we need to put
as (build-)depends in our packages. Once it is done, I will run that
tool before declaring a package dependency as realigned.

Do you have better tooling, and do you maybe prefer using "cme" instead
of pkgos-reqsdiff (I don't as cme doesn't know about Pythonic
{test-,}requirements.txt ...)?

James, Chuck, Corey, does this plan looks good to you?

Cheers,

Thomas Goirand (zigo)