On Mar 02 06:53, Bohuslav Kabrda wrote:
> ----- Original Message -----
...SNIP...
>
> I think applications should use /usr/bin/python3.4 (at least packaged
> applications). Otherwise we could theoretically end up in a situation where
> /usr/bin/python3 is owned by python35, but the application RPM still has
> python34- dependencies and thus the app doesn't work.
>
> I think this is actually one of the reasons why I thought it makes sense to
> keep both python34 and python35 living together in the state where python35
> is the main python3 (having the default macros and owning /usr/bin/python3)
> and python34 is the "other". Let's take this example:
> - there's an application "foo" written in python, which requires "six"
> - it doesn't make sense to build the application for both python34 and
> python35, since it's an application, not a library
> - this means it doesn't make sense for package maintainer to introduce the
> %python3_{other or next}* macros to the specfile, maintainer just wants to
> build with "the python3"
> - so this means that we should do this:
> -- python 3.5 is released, we build it in EPEL and turn with_python3_other to
> 1 in python3-pkgversion-macros
> -- then there's a period when python34 and python35 coexist and python34 is
> "the main python" - in this period, *libraries* are rebuilt to provide both
> python34- and python35- subpackages
> -- python34 and python35 are switched (the default macros now point to 35 and
> it also owns /usr/bin/python3 now)
> -- then there's a period when python34 and python35 coexist and python35 is
> "the main python" - in this period, *applications* are rebuilt for python35
> (may take some time, there will likely be a period when there are some apps
> on python34 and some already on python35)
^ Is this step part of a coordinated mass-rebuild, or is this just a
period of time after we make the announcement: "Hey Packagers: be sure
to rebuild for python35"?
One alternative might be to do python35 in a side tag, after which we
could release the libraries and applications, and deprecate python34
together. This might take quite a bit more work though.
> -- when all applications are rebuilt for 35, with_python3_other is set to 0
> and we now have just python35 and it's the "main" python3
>
> Does this make sense or am I missing something? I'd need to do some minor
> changes+explanations to my proposal to accomodate this, but I still think it
> makes sense.
>
> > What about all of the old python34 packages left on their systems after
> > retirement? Is there some way they can get cleaned up automatically?
>
> I'm not sure about that... and I'm also not sure we want to do that, people
> may still want to keep these around for their own non-system applications to
> migrate.
Great discussion so far!
Brian
--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
