| 1 |
On 8/3/21 8:29 AM, cal wrote: |
| 2 |
> On 8/2/21 11:03 PM, n952162 wrote: |
| 3 |
>> On 8/3/21 7:37 AM, cal wrote: |
| 4 |
>>> On 8/2/21 10:26 PM, n952162 wrote: |
| 5 |
>>>> On 8/3/21 7:20 AM, n952162 wrote: |
| 6 |
>>>>> On 8/2/21 10:10 PM, David Haller wrote: |
| 7 |
>>>>>> Hello, |
| 8 |
>>>>>> |
| 9 |
>>>>>> On Mon, 02 Aug 2021, n952162 wrote: |
| 10 |
>>>>>>> !!! All ebuilds that could satisfy |
| 11 |
>>>>>>> "dev-python/isodate[python_targets_python3_8(-)?,python_targets_python3_9(-)?]" |
| 12 |
>>>>>>> |
| 13 |
>>>>>>> |
| 14 |
>>>>>>> have been masked. |
| 15 |
>>>>>>> !!! One of the following masked packages is required to complete your |
| 16 |
>>>>>>> request: |
| 17 |
>>>>>>> - dev-python/isodate-0.6.0-r2::gentoo (masked by: EAPI 8) |
| 18 |
>>>>>>> |
| 19 |
>>>>>>> The current version of portage supports EAPI '7'. You must upgrade |
| 20 |
>>>>>>> to a |
| 21 |
>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 22 |
>>>>>>> newer version of portage before EAPI masked packages can be |
| 23 |
>>>>>>> installed. |
| 24 |
>>>>>> You should read a bit more carefully... It seems your sys-apps/portage |
| 25 |
>>>>>> is a bit dated. |
| 26 |
>>>>>> |
| 27 |
>>>>>> Upgrade sys-apps/portage first, then it should work. |
| 28 |
>>>>>> |
| 29 |
>>>>>> HTH, |
| 30 |
>>>>>> -dnh |
| 31 |
>>>>> I read that, but I last updated 2 months ago. So, this update breaks |
| 32 |
>>>>> because portage was updated and new ebuilds using that are already |
| 33 |
>>>>> being pushed out? Seems strict to me ... but /isodate/ being the only |
| 34 |
>>>>> one? I still have a EAPI 4 on my system (1). Plenty of EAPI 5. Was |
| 35 |
>>>>> there something in isodate that needed to be urgently updated - |
| 36 |
>>>>> utilizing the the cutting edge EAPI? |
| 37 |
>>>>> |
| 38 |
>>>> We just had to update portage not so long ago. I admittedly presumed at |
| 39 |
>>>> first that something else must be wrong, because it didn't occur to me |
| 40 |
>>>> that portage would be so volatile. |
| 41 |
>>>> |
| 42 |
>>>> Everything in gentoo is so nicely configurable, but I think another |
| 43 |
>>>> dimension should be add: configurable volatility - i.e. a configurable |
| 44 |
>>>> hysteresis for upstream updates. |
| 45 |
>>>> |
| 46 |
>>>> |
| 47 |
>>>> |
| 48 |
>>> It sounds like you would be more satisfied with a distribution that has |
| 49 |
>>> releases. You are fighting a losing battle to use a rolling-release |
| 50 |
>>> distribution on a machine you intend to update infrequently. |
| 51 |
>>> |
| 52 |
>>> Keeping old software working in a rolling release ecosystem is a pain, |
| 53 |
>>> doubly so if you have to maintain the newer version in parallel. What |
| 54 |
>>> you ask for is more difficult than you think. |
| 55 |
>>> |
| 56 |
>> Well, what you say is likely true, but does "old software" really need |
| 57 |
>> to be kept working? Couldn't problems necessarily only be dealt with |
| 58 |
>> in the newest versions? |
| 59 |
> Old software does not exist in a vacuum. Old software has old |
| 60 |
> dependencies; those dependencies get updated in ways that are |
| 61 |
> incompatible, or stop working, or a new version of Python is released |
| 62 |
> with which the old version of the software is incompatible; etc. Or as |
| 63 |
> you've noticed with Portage, the old version of the software may not |
| 64 |
> work compatibly with newer packages, so now you have to maintain older |
| 65 |
> versions of those packages as well... |
| 66 |
|
| 67 |
|
| 68 |
Intuitively, i.e. from vague experience, I know you're right, but I |
| 69 |
can't think it through ... a release would be a snapshot of a working |
| 70 |
configuration at a point in time. |
| 71 |
|
| 72 |
Ah, perhaps the problem is ... in my case, I could make a distribution |
| 73 |
out of what I emerge every month and distibute that - an intermediate |
| 74 |
level of hysteresis. But that's just the system as I require it. A |
| 75 |
Ubuntu makes all those decisions for all supported packages, an effort |
| 76 |
that doesn't interest me... |
Archives