Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 43 |
Nodes: | 6 (0 / 6) |
Uptime: | 97:14:15 |
Calls: | 290 |
Files: | 904 |
Messages: | 76,468 |
There wasn't an introduction message to this series, but I wanted to
raise the discussion.
We only JUST got rid of the last EAPI6 ebuilds in the main tree.
There are overlays that still have EAPI6 ebuilds - and depend on these ebuilds.
When is an expected time for all of those ebuilds to migrate, and how is
that being communicated?
On 8/27/24 5:03 PM, Robin H. Johnson wrote:
There wasn't an introduction message to this series, but I wanted to
raise the discussion.
We only JUST got rid of the last EAPI6 ebuilds in the main tree.
There are overlays that still have EAPI6 ebuilds - and depend on these
ebuilds.
When is an expected time for all of those ebuilds to migrate, and how is
that being communicated?
If we were removing an eclass that only supports EAPI 6 and is being
dropped because it's useless, we'd last rite it and give people 30 days
to move.
But because the *file* isn't being removed, there is no rule how to do
it apparently?? :D The obvious answer here is to stick an ewarn in the
"if EAPI 6" branch at global scope.
(It's a bit messy when doing dependency calculation. This too is a
feature, if you think about it.)
On Tue, 27 Aug 2024, Robin H Johnson wrote:
We only JUST got rid of the last EAPI6 ebuilds in the main tree.
There are overlays that still have EAPI6 ebuilds - and depend on these ebuilds.
When is an expected time for all of those ebuilds to migrate, and how
is that being communicated?