Re: [gentoo-user] dev-python/isodate breaks my emerge because it's at EAPI?

[cal]

On 8/2/21 11:03 PM, n952162 wrote:
> On 8/3/21 7:37 AM, cal wrote:
>> On 8/2/21 10:26 PM, n952162 wrote:
>>> On 8/3/21 7:20 AM, n952162 wrote:
>>>> On 8/2/21 10:10 PM, David Haller wrote:
>>>>> Hello,
>>>>>
>>>>> On Mon, 02 Aug 2021, n952162 wrote:
>>>>>> !!! All ebuilds that could satisfy
>>>>>> "dev-python/isodate[python_targets_python3_8(-)?,python_targets_python3_9(-)?]"
>>>>>>
>>>>>>
>>>>>> have been masked.
>>>>>> !!! One of the following masked packages is required to complete your
>>>>>> request:
>>>>>> - dev-python/isodate-0.6.0-r2::gentoo (masked by: EAPI 8)
>>>>>>
>>>>>> The current version of portage supports EAPI '7'. You must upgrade
>>>>>> to a
>>>>>        ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> newer version of portage before EAPI masked packages can be
>>>>>> installed.
>>>>> You should read a bit more carefully... It seems your sys-apps/portage
>>>>> is a bit dated.
>>>>>
>>>>> Upgrade sys-apps/portage first, then it should work.
>>>>>
>>>>> HTH,
>>>>> -dnh
>>>>
>>>> I read that, but I last updated 2 months ago.  So, this update breaks
>>>> because portage was updated and new ebuilds using that are already
>>>> being pushed out?  Seems strict to me ... but /isodate/ being the only
>>>> one?  I still have a EAPI 4 on my system (1). Plenty of EAPI 5.  Was
>>>> there something in isodate that needed to be urgently updated -
>>>> utilizing the the cutting edge EAPI?
>>>>
>>> We just had to update portage not so long ago.  I admittedly presumed at
>>> first that something else must be wrong, because it didn't occur to me
>>> that portage would be so volatile.
>>>
>>> Everything in gentoo is so nicely configurable, but I think another
>>> dimension should be add: configurable volatility - i.e. a configurable
>>> hysteresis for upstream updates.
>>>
>>>
>>>
>> It sounds like you would be more satisfied with a distribution that has
>> releases.  You are fighting a losing battle to use a rolling-release
>> distribution on a machine you intend to update infrequently.
>>
>> Keeping old software working in a rolling release ecosystem is a pain,
>> doubly so if you have to maintain the newer version in parallel.  What
>> you ask for is more difficult than you think.
>>
>
> Well, what you say is likely true, but does "old software" really need
> to be kept working?  Couldn't problems necessarily  only be dealt with
> in the newest versions?
Old software does not exist in a vacuum.  Old software has old
dependencies; those dependencies get updated in ways that are
incompatible, or stop working, or a new version of Python is released
with which the old version of the software is incompatible; etc.  Or as
you've noticed with Portage, the old version of the software may not
work compatibly with newer packages, so now you have to maintain older
versions of those packages as well...
>
> Yes, a release distribution would be one end of the configuration
> spectrum I'm thinking of.   That works for other distibutions.
>
> My problem is, I want a source distribution.  Maybe there's something
> about source distributions that dictates a rolling strategy?  I don't
> see it, but it might be there.
I don't think there is any particular reason this must be dictated; it
is probably a coincidence of the Venn diagram of people who prefer
source distributions and people who prefer rolling release.

Many binary distributions do also have tools for building packages from
source, which could be a solution if there are only specific packages
you wish to customize, but the experience is not as pleasant as Portage.
>
> I've raised this issue before and someone mentioned a derivative of
> gentoo, which sounds promising, but I'm not convinced by that one
> implementation.