----- Original Message -----
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"?
That's a good question. I guess we should standardize how this will be done. Something
like:
- there's an announcement on epel-devel that python35 is the "main python3"
and packagers should rebuild their packagers (and users their apps/scripts/...)
- wait for a week (two?)
- open bugs for packages that haven't been rebuilt during the previous week and get
them fixed ASAP
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.
+1, I don't want to introduce side tags to the process.
> -- 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
Thanks,
Slavek
--
Brian Stinson
bstinson(a)ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk