----- 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 <dcall...@redhat.com>
> Software Engineer, Hosted & Shared Services
> Red Hat, Inc.
Slavek
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
