Provide sample packages spec files/debian equivalents to each component

Registered by Joshua Harlow on 2012-08-10

As there is now a starting of a openstack-requires which will copy itself into the various openstack components (right now just covering pypi versions/packages) it would seem useful to include along with that copying a tool that can be used to generate a spec file (for rpms) and debian package directory (for debian packages) from a combination of the requirement list (may require some translation to distro-specific package names) and from the code into a file which the rpmbuild command can be used with (or the debian equivalent). This way when you check out a components code you not only get the code, you the ability to create a 'generic' package from that code (which can then be improved/patched upon as desired). Since different distros/vendors/users do this themselves right now, it seems useful to provide the basic package definition from which others can 'derive' from to make there own packages.

Possible ways to accomplish:

1. Improve upon http://wiki.meego.com/Spectacle which takes a 'generic' yaml and can possibly create deb/rpm packages
2. Have simple templates which can exist in common + a tool that can convert that template into a generic package (reading in the components dependencies, translating them if needed, and creating deb/rpm packaging descriptor files)

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Joshua Harlow
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

Sprints

Whiteboard

I think it's a pretty huge leap to go from us maintaining a list of python libraries we require to OpenStack providing sample packaging. Obviously, you can't just generate packaging simply from a list of requirements.

There's been much debate about how much in the way of packaging OpenStack itself should provide versus leaving packaging up todownstreams. It's a good idea to pursue that debate and experimenting with having our projects provide semi-autogenerated spec files etc. is one route to take.

However, I don't think we're quite at the point of a concrete plan for what might be added to openstack-common or openstack/requirements and blueprints aren't the best place for brainstorming. So, closing for now, but please do re-open if we get to the point of a more concrete plan and proof-of-concept code for openstack-common.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.