Filing Bugs for Python 3 Switch

Kevin Fenzi kevin at scrye.com
Thu Jan 29 17:35:19 UTC 2015


On Thu, 29 Jan 2015 09:39:28 -0500 (EST)
Bohuslav Kabrda <bkabrda at redhat.com> wrote:

> Not sure about it being the default, but we've been testing it in
> DevAssistant for dependency installation on Python 3 and never
> encountered any problems. I was also contacted by dnf maintainer with
> a question on how to switch "dnf" to use
> "python3-dnf" (package-wise), so I guess that's what will be done for
> F22 (but that's just my guess, dnf maintainer would have to comment
> here).

See the thing there that makes my teeth itch is: dnf has been
massively great about having a long on-ramp. It appeared, it didn't
replace yum, it let people try it out and report bugs, there was a long
time of testing. Thats all great. But now, we switch it to dnf-3 and...
that has not had years of running in rawhide and other releases, it has
not had people testing it and reporting bugs. While the code overlap
could be pretty large, I am willing to bet a shiny us dollar that there
are some python 3 specific bugs lurking in it. 

So, we turn on this not very tested path and immediately try and use it
as default in anaconda and a new release. What happened to our nice
long ramp? Or any ramp? 

> > Even still, that hinges on DNF being the default package manager in
> > F22.  There are some concerns that it won't make it due to rel-eng
> > tooling used to compose the images, etc.  If that's the case, yum
> > will still be required.
> 
> Required, yes, but we'll still have tons of packages built with
> Python 2. I never said that porting rel-eng tooling is the goal for
> F22.

Might be good to note that on the change page: 

We will not be replacing python2 entirely, it and packages that depend
on it will still be available for now. 

> So if more minimal is minimal buildroot, then we can achieve that,
> since it only has python-libs because of gdb and gdb can be rebuilt
> with Python 3 (upstream source is compatible). If that means minimal
> cloud image, then we can do it (we're waiting for the cloud-init
> folks to accept the py3 patches, which should happen any time now).
> If that means content from fedora-live-base.ks, then we can do pretty
> much everything, except of samba (I think) - and Petr Viktorin is
> doing some talking to people to get rid of samba from this config,
> because it seems to be unnecessary there.

ok. So, perhaps we should have a change around this for f22, but it
should be: Python 3 migration improvements or something, not
'default' ? 

> Considering all the information mentioned above and assuming Anaconda
> makes it, I'd say it should be perfectly possible to declare Python 3
> the default. As for the packages that are not in the minimal
> installs, I can always open bugs for them before beta and only those
> maintainers who believe it to be safe can switch.

Yeah, so if anaconda switches we get:

* anaconda switches to dnf (this is already done in rawhide after last
  branch point, so I think it's quite safe/doable).
* anconda switches to dnf-3 (if we land that change. It's gotten 0
  testing that I know of). 
* anconda switches to python3 (it's almost ready, but no telling what
  issues we will hit, it's not even landed yet). 

Should we toss in a UI redesign so we can have Fedora 18 again? 
(sorry, that was rude of me)

Wouldn't it be safer to defer dnf-3 and anaconda-py3 for next cycle,
but make those changes in rawhide after the branch point? Then they
would actually get months of shake out... 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150129/e19adfa6/attachment.sig>


More information about the devel mailing list