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