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