Gentoo Archives: gentoo-dev

From: Sam James <sam@g.o>
To: gentoo-dev@l.g.o
Cc: Ulrich Mueller <ulm@g.o>
Subject: Re: [gentoo-dev] GLEP 83: EAPI deprecation
Date: Thu, 14 Jul 2022 06:10:32
Message-Id: 52B72F18-9BB4-4B15-B69A-004FD953FEA9@gentoo.org
In Reply to: Re: [gentoo-dev] GLEP 83: EAPI deprecation by Arthur Zamarin
1 > On 13 Jul 2022, at 19:50, Arthur Zamarin <arthurzam@g.o> wrote:
2 >
3 > On 13/07/2022 11.12, Ulrich Mueller wrote:
4 >>>>>>> On Mon, 11 Jul 2022, Ulrich Mueller wrote:
5 >>
6 >>
7 >> So, any opinions? Should we go for the longer transition time (and make
8 >> overlay maintainers happy), or for a shorter time so that we can tidy up
9 >> eclasses sooner?
10 >>
11 >> Ulrich
12 >
13 > My personal take on this question. Faster deprecation of EAPI ebuilds in
14 > ::gentoo repo (as we can control it), but longer time until we remove it
15 > from eclasses. Note that I don't mean here deprecation, only removal.
16 >
17 > I think that with current EAPI>=6 state, the "weight of supporting"
18 > EAPI=6 isn't very heavy, so some extra time for overlays will be nice. I
19 > do know that I don't help a lot in eclass maintenance, so if I wrong in
20 > this statement, I won't complain of course.
21 >
22 > Maybe (?) this will also help during bumps of old systems (not that we
23 > care too much, as we give them along timeframe for this and they can use
24 > snapshots of repo, but why not as an extra bonus).
25 >
26
27 Yeah, I broadly agree with this. Making things predictable for
28 downstreams is important.
29
30 Best,
31 sam

Attachments

File name MIME type
signature.asc application/pgp-signature