Re: [gentoo-dev] EAPI usage

[Michael Mol]

On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau <tommy@g.o> wrote:
> Michael Mol schrieb:
>> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@g.o> wrote:
>>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@g.o> wrote:
>>>>
>>>> The primary benefit to the policy that dev's should bump EAPI when
>>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>>>> eventually removed from the tree.
>>>
>>> What is the benefit from removing the old EAPIs?
>>
>> I can answer this one...removing old EAPIs simplifies code for things
>> which need to be EAPI-aware. There are no bugs in code that doesn't
>> exist.
>>
>
> Like package managers?
>
> Sorry, but this is not true, since you can never assume, that older
> EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never
> needed a bump, is enough), so older EAPI versions have to be supported
> forever.

I would assume that's what auditing is for. Unless I'm sorely mistaken
(and I may be; I don't know much at all about eclasses), it should be
fairly simple to script through the tree to find any eclasses or
ebuilds which express a dependency on an EAPI of a given level,
presuming the expression is of a standard form.

Compile a list of existing ebuilds which depend on old EAPIs, and
you've got a TODO list. (eclasses, I don't know; I don't know if
eclasses explicitly express EAPI compatibility in metadata) Once that
list is cleared, yes, you can assume there are no ebuilds with a
specified EAPI of 0. I'd presume it would have been made widely known
that new ebuilds shouldn't use the old EAPI by that point, and so
support for the deprecated EAPI level can be abandoned.

Out-of-tree ebuilds pose their own problems, but that's a matter for
the managers of the relevant overlays.

Now, for the million-dollar question: Who should do the work? My
answer would be "whoever wants it done." Whoever wants the work done
can go through their audit list and submit the relevant patches to the
maintainers. Whether that's a team of twenty people or the work of an
individual with a shell script and a lot of time on his hands, that's
where that kind of work belongs. Now, if a maintainer rejects the
patch, then the submitter can fix the patch to the maintainer's
specifications. If the maintainer rejects the patch on some principle,
that's an issue that can be raised and dealt with rationally at the
time it happens. I imagine most maintainers would welcome assistance,
especially if it means simplifying future work they may need to do.

-- 
:wq