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
bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk