----- Original Message ----- > On Thu, Jan 29, 2015 at 8:56 AM, Bohuslav Kabrda <bkabrda@xxxxxxxxxx> wrote: > > ----- Original Message ----- > >> On Thu, Jan 29, 2015 at 7:38 AM, Miloslav Trmač <mitr@xxxxxxxxxx> wrote: > >> > (Speaking only for myself, not for all of FESCo; hoping others will > >> > chime > >> > in.) > >> >> - What if Anaconda does make it? :) > >> > I don’t know. > >> > >> I'm skeptical that will happen. Even if it does, that alone is likely > >> not enough to claim python3 by default. You need all the basic > >> functionality to work with pthon3, e.g. yum and dnf would also need to > >> be ported. > > > > DNF works with Python 3, Yum will never work with it (this is why the > > change page says that this feature depends on DNF becoming the default > > package manager). I'm regularly talking to some of Anaconda devs (mostly > > Vrata Podzimek) and they still think this is doable *without* introducing > > high number of regressions, that would be impossible to fix before F22 > > final. > > Good to know DNF is already fine in regards to python3. I must have > misunderstood the references to python3-dnf yesterday. I was under > the impression that it was something that existed, but wasn't widely > used or tested at this point. It certainly didn't seem to be the > default dnf that everyone is using in F20/F21 (and rawhide today) > installs. 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). > 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. > > What else is "all basic functionality"? If this is about making Workstation > > LiveCD python2-free, then I'm not sure we can make that even for F23 > > (samba and glusterfs will be hard nuts to crack, although the work on > > samba has already started). > > That might be a good goal, but it wasn't what I was thinking. I was > thinking more along the lines of a more minimal install only requiring > python3 to be installed. I don't have a concrete package set in mind > at the moment. 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. > >> >> - What is "enough"? It's possible that two or three packages may be > >> >> still > >> >> unported even in F23 (and as for server livecd in F23, I think there > >> >> will > >> >> be > >> >> few more). > >> > 2-3 packages should not be an issue, perhaps unless they were very > >> > visible > >> > (e.g. having a public and widely-used Python plugin API). > >> > > >> >> - So is it ok if I file bugs for all components that I know are > >> >> upstream-compatible with Python 3 (bugs to get them switched, I mean)? > >> > > >> > If we are shipping both Python versions anyway, and the specific > >> > packages > >> > are known to be compatible (i.e. there little risk), I don’t see any > >> > reason not to switch them already in F22. > >> > >> I agree with everything Mirek said, as well as his take on the FESCo > >> reasoning. > >> > >> We'd really like to see this happen, we don't want to slow down the > >> work. We just don't feel F22 is a release that is going to accurately > >> reflect the python3 as default status. > > > > What I'm afraid is that by postponing this change, we will have achieved > > nothing else, than half more year of status quo. > > That's understandable, and to be honest a good concern. At the same > time, just declaring something as "default" when reality doesn't > reflect that really won't achieve the actual goal either. FESCo is > hoping that opening the bugs against rawhide after F22 branching will > help prod things along. We'll be happy to revisit at that point and > see if there are other efforts we can help with to make this happen in > F23. 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. > josh > -- Thanks, Slavek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
