Just something to note; anvil has never ran had issues with this (afaik).

It seems fairly easy to have a mapping/algorithm/other... that is used imho (and this is just what anvil has); I don't recall that the number of problems with weird names has been any real issue when building rpms... It's sometimes an annoyance but meh, make better tooling in that case?

Some of the mapping + other tweaks @ https://github.com/stackforge/anvil/blob/master/conf/distros/redhat.yaml#L9

Also the code at:

https://github.com/stackforge/anvil/blob/master/tools/py2rpm#L161 (which does the brute work of most of the openstack *non-core* project package building). The *core* (nova, glance...) project spec files are treated specially @ https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs (these are cheetah templates that are expanded; allowing for conditionals like '#if $newer_than_eq('2014.2')' to work...)

Food for thought,

-Josh

Thomas Goirand wrote:
On 01/24/2015 02:01 AM, Doug Hellmann wrote:

On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
Hi,

I've just noticed that oslo.log made it to global-requirements.txt 9
days ago. How come are we still adding some name.spaced oslo libs?
Wasn't the outcome of the discussion in Paris that we shouldn't do that
anymore, and that we should be using oslo-log instead of oslo.log?

Is three something that I am missing here?

Cheers,

Thomas Goirand (zigo)
The naming is described in the spec:
http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html

tl;dr - We did it this way to make life easier for the packagers.

Doug

Hi Doug,

Sorry for the late reply.

Well, you're not making the life of *package maintainers* more easy,
that's in fact the opposite way, I'm afraid.

The Debian policy is that Python module packages should be named after
the import statement in a source file. Meaning that if we do:

import oslo_db

then the package should be called python-oslo-db. This means that I will
have to rename all the Debian packages to remove the dot and put a dash
instead. But by doing so, if OpenStack upstream is keeping the old
naming convention, then all the requirements.txt will be "wrong" (by
wrong, I mean from my perspective as a package maintainer), and the
automated dependency calculation of dh_python2 will put package names
with dots instead of dashes.

So, what is going to happen, is that I'll have to, for each and every
package, build a dictionary of translations in debian/pydist-overrides.
For example:

# cat debian/pydist-overrides
oslo.db python-oslo-db

This is very error prone, and I may miss lots of dependencies this way,
leading to the packages having wrong dependencies. I have a way to avoid
the issue, which would be to add a Provides: python-oslo.db in the
python-oslo-db package, but this should only be considered as a
transition thing.

Also, as a side note, but it may be interesting for some: the package
python-oslo-db should have Breaks: python-oslo.db (<<  OLD_VERSION) and
Replaces: (<<  OLD_VERSION), as otherwise upgrades will simply fail
(because 2 different packages can't contain the same files on the
filesystem).

So if you really want to make our lives more easy, please do the full
migration, and move completely away from dots.

Also, I'd like to tell you that I feel very sorry that I couldn't attend
the session about the oslo namespace in Paris. I was taken by my company
to a "culture building" session all the afternoon. After reading the
above, I feel sorry that I didn't attend the namespace session instead. :(

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

__________________________________________________________________________
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

Reply via email to