Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
On 12/06/15 13:45 -0400, Russell Bryant wrote: On 06/12/2015 01:31 PM, Dirk Müller wrote: If instead it seems the differences are minor enough that combining efforts is a win for everyone, then that's even better, but I don't see it as the required outcome here personally. Right. We've started with an open discussion and not started with any of those two outcomes in mind already. I think thats also why we agreed to start with a green field and not seed the repos with any of the distro's existing spec files. To me it looks promising that we can mechanically compile the $distro policy conformant .spec file from the canonical upstream naming, and at some point that compile step might end up being a cp. Yikes ... having to start green field and drop history from the last several years seems quite unfortunate. It kind of sounds like too much work to be worth it to me, but I'm just on the sidelines here. Anyway, my main objective was just to make sure nobody felt like combining efforts was the only acceptable outcome. I'm happy with whatever you all end up deciding is most helpful overall. Just wanted to add that I agree with Russell's comments on this topic. I'm a happy observer of this effort but I'd love you all to amke the best decision for these projects and it seems you're working towards that. Cheers, Flavio -- @flaper87 Flavio Percoco pgpOiligp32cC.pgp Description: PGP signature __ 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
Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
Hi Joshua, An example of some specs already doing this (they are built using the cheetah template engine/style): https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs They are turned into 'normal' spec files (the compilation part) during build time. Right, I think thats a good idea, this allows us to work on reducing the differences over time and start with basically what we have today. Greetings, Dirk __ 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-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
Hi, A couple of packagers from RDO and SUSE met today on IRC to kick off brain storming on unified upstream rpm packaging for OpenStack. Please note: there are currently two movements going on: RDO would like to move their Liberty packaging from github.com and gerrithub to openstack gerrit, and RDO and SUSE would like to collaborate on unified packaging. For the rest of the mail I'm only talking about the latter. The agreed goal is that by the time of the Liberty release, we have all something that anyone interested like RDO and SUSE can use for maintaining the packages for the whole Liberty maintenance lifecycle. For the rest of the meeting we were quickly explaining our setups to each other and shortly walked over the list of obvious differences that we need to work on. The meeting minutes have been captured here: https://etherpad.openstack.org/p/openstack-rpm-packaging We're planning to have a followup meetings to work some more on the issues and are currently hanging out on #openstack-rpm-packaging on IRC. Greetings, Dirk __ 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
Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
On 06/12/2015 12:47 PM, Dirk Müller wrote: Hi, A couple of packagers from RDO and SUSE met today on IRC to kick off brain storming on unified upstream rpm packaging for OpenStack. Please note: there are currently two movements going on: RDO would like to move their Liberty packaging from github.com and gerrithub to openstack gerrit, and RDO and SUSE would like to collaborate on unified packaging. For the rest of the mail I'm only talking about the latter. The agreed goal is that by the time of the Liberty release, we have all something that anyone interested like RDO and SUSE can use for maintaining the packages for the whole Liberty maintenance lifecycle. For the rest of the meeting we were quickly explaining our setups to each other and shortly walked over the list of obvious differences that we need to work on. The meeting minutes have been captured here: https://etherpad.openstack.org/p/openstack-rpm-packaging We're planning to have a followup meetings to work some more on the issues and are currently hanging out on #openstack-rpm-packaging on IRC. I'm just kind of curious ... as both the RDO and SUSE folks look closer at this, how big are the differences? I could see one possible outcome where the differences are significant enough that it would be less work overall to just continue to treat them separately. If instead it seems the differences are minor enough that combining efforts is a win for everyone, then that's even better, but I don't see it as the required outcome here personally. -- Russell Bryant __ 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
Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
Hi Russel,
I'm just kind of curious ... as both the RDO and SUSE folks look closer
at this, how big are the differences?
From the overall big picture, we're doing pretty much the same thing.
We have both a tool chain to continuously track changes as they happen
in upstream git, packaging that up and building binary packages there,
testing them in an isolated area with a tempest-like run and when that
succeeds, promote them into the respective stable trees for operators
to consume.
In my personal view, there are surprisingly many overlapping
activities where collaborating makes sense and could save duplicated
effort on both sides.
However, the devil is a bit in the details: Right now there are
differences in the Fedora and openSUSE python packaging guidelines
that are leading to almost the same but slightly different .spec
files. We're looking at unifying those differences up to a point where
the remaining diff, should be anything left, can be handled by a post
processing tool that just generates the distro variant of the spec
file from the upstream spec file.
Just to give you an example (this is not an exhaustive list):
- SUSE requires the use of a spdx.org standardized License: tag in the
spec file, RDO uses something else
- SUSE requires packages to be called python-$pypi_name, while Fedora
escapes more things from the pypi name ('.', '_' and '+' are replaced
by '-' and the name is lowercased). This adds up in differences of
requires/provides/obsoletes/conflicts and so on. This can be likely
solved by substitution and by %if sections, we just need to work on
that.
- Indenting and whitespacing rules seem to be slightly different
between the distros
There are also some conventional changes (in some cases the RDO spec
file is more correctly packaged than the SUSE variant or vice versa)
and those can be easily resolved on a case by case base, and that will
immediately help both user bases.
If instead it seems
the differences are minor enough that combining efforts is a win for
everyone, then that's even better, but I don't see it as the required
outcome here personally.
Right. We've started with an open discussion and not started with any
of those two outcomes in mind already. I think thats also why we
agreed to start with a green field and not seed the repos with any
of the distro's existing spec files.
To me it looks promising that we can mechanically compile the $distro
policy conformant .spec file from the canonical upstream naming, and
at some point that compile step might end up being a cp.
Dirk
__
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
Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
On 06/12/2015 01:31 PM, Dirk Müller wrote: If instead it seems the differences are minor enough that combining efforts is a win for everyone, then that's even better, but I don't see it as the required outcome here personally. Right. We've started with an open discussion and not started with any of those two outcomes in mind already. I think thats also why we agreed to start with a green field and not seed the repos with any of the distro's existing spec files. To me it looks promising that we can mechanically compile the $distro policy conformant .spec file from the canonical upstream naming, and at some point that compile step might end up being a cp. Yikes ... having to start green field and drop history from the last several years seems quite unfortunate. It kind of sounds like too much work to be worth it to me, but I'm just on the sidelines here. Anyway, my main objective was just to make sure nobody felt like combining efforts was the only acceptable outcome. I'm happy with whatever you all end up deciding is most helpful overall. -- Russell Bryant __ 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
Re: [openstack-dev] [packaging] RPM Packaging for OpenStack IRC Meeting
Dirk Müller wrote:
Hi Russel,
I'm just kind of curious ... as both the RDO and SUSE folks look closer
at this, how big are the differences?
From the overall big picture, we're doing pretty much the same thing.
We have both a tool chain to continuously track changes as they happen
in upstream git, packaging that up and building binary packages there,
testing them in an isolated area with a tempest-like run and when that
succeeds, promote them into the respective stable trees for operators
to consume.
In my personal view, there are surprisingly many overlapping
activities where collaborating makes sense and could save duplicated
effort on both sides.
However, the devil is a bit in the details: Right now there are
differences in the Fedora and openSUSE python packaging guidelines
that are leading to almost the same but slightly different .spec
files. We're looking at unifying those differences up to a point where
the remaining diff, should be anything left, can be handled by a post
processing tool that just generates the distro variant of the spec
file from the upstream spec file.
Just to give you an example (this is not an exhaustive list):
- SUSE requires the use of a spdx.org standardized License: tag in the
spec file, RDO uses something else
- SUSE requires packages to be called python-$pypi_name, while Fedora
escapes more things from the pypi name ('.', '_' and '+' are replaced
by '-' and the name is lowercased). This adds up in differences of
requires/provides/obsoletes/conflicts and so on. This can be likely
solved by substitution and by %if sections, we just need to work on
that.
- Indenting and whitespacing rules seem to be slightly different
between the distros
There are also some conventional changes (in some cases the RDO spec
file is more correctly packaged than the SUSE variant or vice versa)
and those can be easily resolved on a case by case base, and that will
immediately help both user bases.
If instead it seems
the differences are minor enough that combining efforts is a win for
everyone, then that's even better, but I don't see it as the required
outcome here personally.
Right. We've started with an open discussion and not started with any
of those two outcomes in mind already. I think thats also why we
agreed to start with a green field and not seed the repos with any
of the distro's existing spec files.
To me it looks promising that we can mechanically compile the $distro
policy conformant .spec file from the canonical upstream naming, and
at some point that compile step might end up being a cp.
An example of some specs already doing this (they are built using the
cheetah template engine/style):
https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs
They are turned into 'normal' spec files (the compilation part) during
build time.
Perhaps something similar can be done (ideally using jinja2 or better,
since cheetah the project seems to be mostly dead...)
Dirk
__
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
