On 26 June 2015 at 23:01, Matthew Booth <mbo...@redhat.com> wrote: > I wrote this: > > https://review.openstack.org/#/c/195983/1/tools/de-pbr.py,cm > > Ideally we'd fix PBR, but this seems to be expected behaviour. Thoughts?
Hi Matt, thanks for raising this. We've had very mixed results trying to figure out what issues distribution packagers are having with pbr - we have a couple of mechanisms already for them: - you can tag - a tagged commit has the version of the tag - you can use PBR_VERSION (per http://docs.openstack.org/developer/pbr/packagers.html) The error you complain about in that review is saying that that config file specifies a version number that *cannot* be satisfied. Versions have to increase, they can't go backwards. There are several things that could combine to create this contradiction: for instance, say you have two commits, B the most recent commit and A the commit before it. There's also a tag 2014.1.4 that points at A. B cannot have a version lower than 2014.1.5: because if B had a version of 2014.1.4, the tag pointing at A would be false. If B had a version of 2014.1.4a1 or anything like that, B would have a lower version than A. But the config file in nova at the time this error was raised says 'The version of the next release WILL BE 2014.1.4'. Thus PBR has been given contradictory instructions, and throws its hands up in the air. We could perhaps instead just *ignore* setup.cfg's version line. That would mean that you'd get 2014.1.5, but this would be very surprising to folk that have been putting versions in setup.cfg, so we didn't do that. I don't know if that would solve the issue you were having. We could remove the version = line from setup.cfg's across the board, and Doug and Thierry are considering that. The pbr team (loosely oslo+infra) are very open to discussion about the right way to do things, for both upstream and packagers, and would welcome a bug report describing any confusing or problematic situation you might find yourself in in future. I know of two important bits of work at the moment; firstly I've promised to write up a spec about making pbr suitable for use in some of the Python packaging tools [virtualenv and pip specifically], which will involve being able to ship sdists that have no setup_requires. I believe this will be attractive to distribution packagers as well. Secondly, some folk are interested in supporting local version segments in the PEP-440 version string - I'm keen on that too, but it needs (IMNSHO) to align in with the Nova/Cinder etc 'vendor version' feature from their config files - we should consolidate that logic into pbr, as its really got nothing to do with any one API server per se. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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