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
