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