----- 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
> 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
