| 1 |
On 10/04/2017 01:59, Michael Orlitzky wrote: |
| 2 |
> On 04/09/2017 07:15 PM, William L. Thomson Jr. wrote: |
| 3 |
>> |
| 4 |
>> If the package failed, all that would need to be done kinda like now is |
| 5 |
>> a given variable modified in the ebuild. Just marking what ever it did |
| 6 |
>> not work with. As mentioned that could be done via my |
| 7 |
>> ebuild-batcher[1], though same functionality is easily replicated. |
| 8 |
>> |
| 9 |
> |
| 10 |
> How do you plan to test a thousand packages against the new version of |
| 11 |
> python, and then revision/stabilize all of the broken ones |
| 12 |
> immediately? Or is the plan to just break everyone's systems, and ask |
| 13 |
> them to report bugs for the things that stopped working? |
| 14 |
python 3.5.0 was released on 2015-09-13 and is still marked unstable and |
| 15 |
until recently was unusable because there were too many missing packages |
| 16 |
marked ready for it, stabilization isn't that faster right now. |
| 17 |
Most of the breakage would be caught when recompiling (bytecode) of a |
| 18 |
package stable or not and even when not caught it would trigger only |
| 19 |
eselecting an unstable dev-lang/python if testing all python packages is |
| 20 |
required to stabilize dev-lang/python (which is kinda the current |
| 21 |
situation). |
| 22 |
|
| 23 |
Python is slotted, that would also help a lot at keeping the breakage |
| 24 |
unobtrusive * |
| 25 |
* Provided portage is never broken by a dev-lang/python update, but |
| 26 |
that's easy to test. |
| 27 |
|
| 28 |
|
| 29 |
> |
| 30 |
> I think what you will actually get as a result is that nobody will |
| 31 |
> ever add a new version of python to the tree, because you've just made |
| 32 |
> it a huge ordeal to do so. |
| 33 |
> |
| 34 |
I do respectfully disagree with this sentence. |
Archives