EPEL RFC: Strategy for python3 versions

[Toshio Kuratomi]

On Tue, Apr 29, 2014 at 07:22:40PM -0600, Orion Poplawski wrote:
> 
> So, I want to be explicit as to how we handle python3 modules in EPEL.
>  Originally I was hoping we could simply have python3.4 provide
> python3 and maintainers could branch their current Fedora python
> modules for epel7 and build as is resulting in python3-module packages
> as in Fedora.
> 
> However, I don't see how we transition easily to the next python3
> release.  I suppose we could do a side tag and rebuild everything then
> have a flag day release.  Does this seem workable (I don't think so)?
> 
I agree, this doesn't seem workable.

> If we're going to require having python34-module packages are we going
> to require new reviews, or can we simply have people name them with
> %package -n python34-module in the epel7 branch?  Would we have people
> maintain multiple versions at a time in a package?  This seems like
> the workable version.  I'm afraid that requiring new review all the
> time will be a serious impediment.
> 
> We'll have %{__python34} etc macros then too.
> 
I hadn't thought about doing things that way but it sounds pretty
attractive.  There are two things that I'm not sure about:

* How do we handle updating the version of a module between python3.N and
  python3.N+1?
  - Perhaps we violate the 1 upstream tarball per-package rule and have one
    tarball for python-3.N and a second tarball for python-3.N+1?  I think
    doing this would have the same drawbacks as we normally think of for
    this case: we'll have to make updates to only one of the tarballs and
    that will cause new binary rpms to be created for both of the
    subpackages.  So users will have to download packages with no changes.
    I think we need to figure out a better solution to this problem.
* How does this interact with Fedora and RHEL/EPEL python modules?
  - We probably don't want to share spec files with the main Fedora python
    modules (those will build a single python2 and a single python3 module
    from a single tarball so they're very different) or the RHEL python
    modules (those will build a single python2 module from a single
    tarball).
  - So we probably need a different package namespace.  Since RHEL6/7
    doesn't have python3 we could use python3-foo for srpms and create
    python3.N-foo subpackages for the binary rpms.  Do we need to worry
    about this clashing with packages in Fedora space at all?
    + We wouldn't want Fedora bugzilla to get these package names: maybe we
      have to talk to scm admins about creating packages with no rawhide
      branches [to prevent the pkgdb-bugzilla sync scripts from creating
      a bugzilla entry for them in Fedora]
    + Sometimes upstreams produce a python3 module as a separate tarball
      from the python2 version.  In those cases, Fedora would have
      a separate python3-foo srpm package since it would follow the
      one-tarball-per-package "rule".  We could simply re-use the srpm
      package name without re-using the spec file.  EPEL is probably
      different enough from Fedora that this isn't a problem.

If the problem is re-review (and not maintaining multiple packages) an
alternative might be to short-circuit the review process for these packages.
We can specify in EPEL guidelines that these packages can be reviewed for
differences from the previous EPEL module version rather than a full review.
This is somewhat similar to the package rename case in Fedora which hasn't
been a major bottleneck there but it isn't a problem on the same scale as
we're talking about here.  I think if we could solve the above issues,
a single package would make more sense.

> 
> I like the plan of supporting 2 versions at a time.  I'm willing to
> defer deciding on what the next version should be till later.  Perhaps
> 3.5 won't be all that compelling and we'll want to wait for 3.6.
> 
> Finally:
>    python34-3.4

This has precedent.

> or python3.4-3.4

When I create new compat packages, I like to put dots in the version so
this works for me as well.

> or python-3.4-3.4

I dislike dashes in that position as it makes it hard to read.

> or python3-3.4-3.4?

I still dislike dashes but I can see how this would make logical sense if
we name module srpm packages python3-foo and module binary rpm packages as
python3-3.4-foo.  If we name the modules packages python3-foo.src.rpm and
python3.4-foo.noarch.rpm, though, then I'd rather use one of the dash-less
versions above.

> Keep provides python(abi) = 3.4?
> 
I think so.  This is what the python3 package in Fedora does and what the
python26 package in EPEL5 does.  It hasn't caused problems in those places.
I think that it means what we intend to say.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140430/16de8ccf/attachment.sig>