On Sun, 9 Apr 2017 23:44:50 +0200 Kristian Fiskerstrand wrote: > On 04/09/2017 06:15 PM, 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? > > It would only work if upstream provide a strong assurance for forward > compatibility. Explicit testing and marking working seems the only > practical way to ensure stability. Even if things break, you just do the opposite of now. You would disable/mask ( or something to that effect ) any versions the package did not support. Basically what is done now but in reverse. Say what it does not build with; allowing it to build with anything it can, existing today, or coming in the future. In theory at least one would have to modify less ebuilds that break with a new version. Than modifying all adding a new target. There is also the added bonus when a version is dropped. No ebuilds need be modified. I assume if say python 3.4 is dropped. All ebuilds with that target need to be updated. This would considerably reduce work all around, with a much better experience for the end user. No targets to fool with. -- William L. Thomson Jr.