----- Original Message -----
Excerpts from Orion Poplawski's message of 2015-02-28 04:36
+10:00:
> all python34 packages are retired
Except there is no way to retire an individual subpackage, is there?
Instead we are saying, the python34-* subpackage will just go away.
Yeah, I'm still not sure how this should be handled. Does anyone know whether the
python34- subpackage will disappear from the repo if only python35- is built in a newer
build? I'd tend to think so, since I think Koji builds repos from the newest builds,
so if the package is rebuilt without python34- subpackage, it won't be there when the
repo regenerates... But maybe I'm completely wrong here.
> What I still don't understand is what this looks like on the
user end,
> how do they go from 34 to 35? For app users (#!/usr/bin/python3), it
> seems like this should be as automatic as possible. So shouldn't they
> still use /usr/bin/python3 rather than /usr/bin/python3X so they get
> updated automatically?
>
> What about all of the old python34 packages left on their systems
> after retirement? Is there some way they can get cleaned up
> automatically?
Well I guess normally when a subpackage goes away (because it is being
renamed or subsumed into some other package) the replacement would add
Provides and Obsoletes to handle the upgrade path.
But I don't think we want the python35-* packages to Provide/Obsolete
the python34-* packages because then everyone will be automatically
upgraded to the 3.5 stack as soon as it appears, in which case why are
we even bothering with python3x-* at all?
Yeah, my intention was to build these two stacks without any
conflicts/obsoletes/replacements.
Under the current proposal every package with Python 3 dependencies
would have to depend on a specific python3x-* package, so then it would
be up to the maintainers of all those packages to manually bump their
Requires from python34-* to python35-* at some point. Which, now that
I think about it, is not that great. Even worse, if any packages form
a transitive dependency chain then *all* packages in the chain have to
update their Requires at the same time to avoid having a mix of
python34-* and python35-* requirements.
Not really. The requires/buildrequires should be in form of
Requires: python%{python3_pkgversion}-six
so when we change %python3_pkgversion in the minimal buildroot, maintainer just rebuilds
and gets updated requires.
So we probably need to make the python3x-* subpackages provide
python3-*
= %{version}-%{release}. Maybe Bohuslav already had this in mind, but
it's not mentioned on the proposal page. So then packages would just
require python3-* as they do in Fedora, and when the python35-* stack
appears yum/dnf would just automatically upgrade. The /usr/bin/python3
symlink means that everything will just keep working for applications.
On the other hand, if someone has explicitly installed a library (yum
install python34-requests), for example because they are developing
against it, then I guess they will left with the 3.4 build forever. It
is up to them to install python35-requests if/when they are ready.
Yeah, I agree. We *will* make it possible to update with a simple rebuild as mentioned
above, since we'll be able to control the value of %python3_pkgversion in the minimal
buildroot.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
Slavek