Ühel kenal päeval, E, 10.04.2017 kell 16:01, kirjutas William L. Thomson Jr.: > On Mon, 10 Apr 2017 22:51:35 +0300 > Mart Raudsepp <l...@gentoo.org> wrote: > > > > After testing they actually work with the new version, instead of > > throwing known breakages onto ~arch users. > > Ebuilds cannot use the new version till it is added to their > PYTHON_COMPAT correct? > > There does not seem to be any way around touching all ebuilds when > adding a new version. > > > > Am I missing something? > > > > You are missing the fact that this is pure janitorial in case of > > removal of a python3 SLOT, which can be done with scripts in one > > big > > commit. > > Ok I concede on removing older versions. Lets put old version aside. > > What about adding new? You still have to add the new version to > PYTHON_COMPAT in each ebuild right? > > What about users? Do they need do anything if they have specific > targets > set? Or all should just use Wildcard and if in ~arch have 3-4+ > pythons. > > Even if house cleaning, removing old is not an issue. You still have > adding new, and the end user experience.
The user experience is suboptimal either way. Some ideas to improve that seems to be e.g something like Kent brought up. But all this requires manpower and so on to actually do; potentially also limiting potential manpower to whom has or can get some deep graph theory knowledge. Explicitly adding things is better, so you don't get some huge unknown breakages of some lower level module not working and then having to work your way towards all consumers and adding the fact they don't work there too, because a dependency doesn't work. The reverse is not feasible due to the breakages, and when you are entering automated testing to catch breakages, you might as well do automated testing and semi-automated addition to PYTHON_COMPAT for stuff that succeeds in this automated testing. We are stuck on defaulting to 3_5 mostly because not everything having 3_5 in COMPAT isn't stable yet or whatnot, combined with python teams conscious decision to tie the stabling of a new dev-lang/python SLOT (that didn't have stable versions before) to flipping default PYTHON_TARGETS as well, and then the tracker bug for that being delayed or something. Mart
