1 |
On Sun, 9 Apr 2017 23:36:18 +0200 |
2 |
Francesco Riosa <vivo75@×××××.com> wrote: |
3 |
|
4 |
> On 09/04/2017 18:15, William L. Thomson Jr. wrote: |
5 |
> > Not sure if this is practical, it may be less work if the use of |
6 |
> > Python and Ruby versions ( maybe others ) is reversed. Rather than |
7 |
> > adding all the versions that the ebuild supports. What if it only |
8 |
> > included versions it did not support? |
9 |
> > |
10 |
> > Rational |
11 |
> > When new versions are added. Ebuilds must be updated to support the |
12 |
> > new version. This can require editing a decent amount of ebuilds. |
13 |
> > Many may work fine with the new version. Making this extra needless |
14 |
> > work. From a user point of view, You cannot move to the newer |
15 |
> > version without keeping older around till all are updated to the |
16 |
> > newer version. |
17 |
> > |
18 |
> > Now one could say its the same work to mark versions not supported. |
19 |
> > But I think there is less of that. Also if something supports and |
20 |
> > older version and not newer, it may stand out more failing. |
21 |
> > Requiring someone to reduce to the older version, and maybe filing |
22 |
> > bugs to get it updated to the newer version. |
23 |
> > |
24 |
> > Python 2.7 stuff aside. I am not sure how many Python and Ruby |
25 |
> > packages break with a newer release. In pythons case I think once |
26 |
> > they support Python 3.x, there is little chance if it breaking with |
27 |
> > further 3.x releases. Not sure about Ruby. |
28 |
> > |
29 |
> > I could be very wrong and the present way of doing things being the |
30 |
> > only way. However if this is feasible it may lead to less work. It |
31 |
> > would allow all packages to move to a newer version. Also allowing |
32 |
> > punting of older sooner. This leaves the versions solely up to the |
33 |
> > eclasses. Then ebuilds simply mark the unsupported versions. Just |
34 |
> > like we do now with adding versions it does support. |
35 |
> > |
36 |
> > Which if something was say only Python 2.7. It would have a >= to |
37 |
> > excluded any newer version of Python. That said, we could do the |
38 |
> > same with the current way. Saying this supports Python/Ruby >=SLOT. |
39 |
> > |
40 |
> > Either way I do not think the current way is the best way. You have |
41 |
> > to add every version/slot to ebuilds that work fine with any |
42 |
> > version. When new ones are added, the ebuild has to be touched |
43 |
> > again. When it may work fine with a new version without requiring |
44 |
> > the ebuild to be modified. |
45 |
> > |
46 |
> > This came up with some stuff requiring ruby23 as I moved to 24. |
47 |
> > Looking around some stuff has Python 3.5 some 3.6, but all 3.4. So |
48 |
> > I will stick to 3.4 till everything is at 3.6. Otherwise no point |
49 |
> > and still have other versions. |
50 |
> > |
51 |
> > The approach mentioned above, if the packages do not have issue. I |
52 |
> > could go ahead and switch to ruby24 and pyton 3.6 across the board. |
53 |
> > Which I cannot do now till a bunch of ebulids have their targets |
54 |
> > increased. |
55 |
> > |
56 |
> +1 to the python part, cannot speak about ruby. |
57 |
> or totally automate the addition of python versions to ebuilds at the |
58 |
> exact time of bumping dev-lang/python. |
59 |
> |
60 |
> |
61 |
|
62 |
|
63 |
This could be partially automated using buildbot. The easiest would be |
64 |
for pkgs containing working test suites. Those that pass could be |
65 |
auto-enabled with that python with ~arch keywords. I think if a stable |
66 |
pkg is to be added the new python, it should be via a revision bump and |
67 |
~arch'ing the keywords. But we could enforce the bot to rev-bump all |
68 |
ebuilds just as easily. |
69 |
|
70 |
Pkgs without tests, those would be harder and |
71 |
we could do some basic tests on those, like syntax, test imports, but |
72 |
would require additional means of testing in order to qualify for an |
73 |
auto-python addition. |
74 |
|
75 |
It should also be possible for the bot to scrape setup.py for |
76 |
comppatible python versions. Many of the pkgs I have been working with |
77 |
recently have them listed. Also there is travis.yml files in many |
78 |
upstream pkg repos which can also be scraped for tested pythons. |
79 |
|
80 |
It could certainly reduce the manpower needed to keep things up to date. |
81 |
|
82 |
-- |
83 |
Brian Dolbec <dolsen> |