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

[James Page]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Thomas

On 05/06/15 14:54, Thomas Goirand wrote:
[...]
>> 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?

In Vancouver, I agreed that we would focus on converging the
dependency chain for OpenStack between Ubuntu and Debian, as that
brings immediate benefit to both distros.

We're not ready to commit on converging the core packaging yet - as I
detailed on the openstack-dev ML thread re packaging.

That said I'll still respond on the Debconf stuff as its pertinent to
any package upstreaming that might happen.

I'm still have strong reservations about including debconf/dbconfig in
the packaging at-all - with either of the options above we increase
the complexity of the packaging, even if the Ubuntu binaries ship
without any of it included as you detail in 2).

Anyone making packaging changes has to be aware that they might impact
on the debconfig/dbconfig bits you want for Debian - so it increases
the risk of change and the general brittleness of the package source.

With regards to dependency versioning, I think we need to take a more
holistic approach in the distros - we need to be aware of when we're
using a packaged version which is not within the bounds that upstream
think we should be using.

Developing a lintian check for this might be a better idea - that way
*any* version mismatch for a python package in the archive will be I
or W level warned about.

I guess what I'm saying is that this is a general python distribution
challenge, not an OpenStack specific one - lets not make a solution in
isolation!

- -- 
James Page
Ubuntu and Debian Developer
james.page at ubuntu.com
jamespage at debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVdYzlAAoJEL/srsug59jDP2IP/RQJ1kTTAhjr3e1BBOx6MMnd
ItZci2AwEopAMj19WGM2we7EGYlSeuQXKRLx7B2Pj75+zN71waR/vQKA2wz2/AmT
oQ+T7Dpc3dG73XmyzPoMm9T9hKDZYt9T3ivuTiDo7/9c+GSo0Lz8ncNL7VqkrEk7
3zDvFBmk8fgHVmzNm7FF6yWdmrKj6diSdmW59jR9Ao7TmJzlL5BWRo7Cf6bgbL2Z
TP2BdMeWrkc/3xz0LaF9w2lXXijMVygOYRoeAWp2wobS2xCEBsUg8iF+E6b2U7pk
qHnaIQhraenKGCR6s7luSekJDOwBDVukRyapBRDG/E0oe7PEZJ+mrsUKwOQ+9/2r
7T5VmzA405oLDIYEr6eP1a2rS/rg5g+R4hxWmXxP0mWpVBN5VAGt7brHMIff/U5a
9ByJfyfzuYYDc34yMxaI0xMzNHRZuQd4dgfxXg1fFYCo2Ux6h+gZDtio9hATaHjg
u0iX6vu4AjAzcRNWM4vk8gA5/1uq3cGD3WXislZgDDGjVD7lg9d9vB6VxFhw10Fq
/+EBxSPzYlLGwRqfnpB0kJuVF06+YaLKY0Du+nqvIXkQ7N5GIXLpw9IibzMozzu9
75SvnXWrjeQJwWwWSN3xNEIGw0mGzf1ksOBm1LtiFLpEHPPouaP6hv2yweW7d9WA
nD1yEmdiwTTJxIXJcRel
=JVkk
-----END PGP SIGNATURE-----