On Thu, 29 Jan 2015 09:39:28 -0500 (EST)
Bohuslav Kabrda <bkabrda(a)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