1 |
On Mon, 10 Feb 2014 08:23:51 -0500 |
2 |
"Anthony G. Basile" <blueness@g.o> wrote: |
3 |
|
4 |
> On 02/10/2014 07:43 AM, Patrick Lauer wrote: |
5 |
> > EAPI 4 becomes deprecated when/if there's a new EAPI allowed in-tree |
6 |
> > (EAPI 6, most likely) |
7 |
> |
8 |
> I am concerned about making this a "rule". |
9 |
|
10 |
Maybe rather a rule with exceptions, or a rather strong recommendation; |
11 |
as we've seen easier, sometimes a rule needs a revision. |
12 |
|
13 |
> While I think its okay for the 4/5/6 move, I'm not sure if it will |
14 |
> always be a good idea. 1) "Deprecating" an EAPI can mean breakage --- |
15 |
> see my next point. 2) To tie the deprecation of the older EAPI to the |
16 |
> introduction of a newer one can delay the introduction of the newer |
17 |
> one and possibly needed features. You will connect the question of |
18 |
> "are we ready to deprecate X" with the question "we need to introduce |
19 |
> Y for needed features a, b and c." |
20 |
|
21 |
It is hard to grasp for me for when features from a newer EAPI would |
22 |
delay the migration, do you have an example? |
23 |
|
24 |
> The statement "Deprecating an EAPI can mean breakage" depends on what |
25 |
> we mean by "deprecating." I'm assuming here we mean something like |
26 |
> repoman won't allow commits at EAPI=1,2,3 but that ebuilds in the |
27 |
> tree at those EAPI's will continue working. Eg. dosed which was |
28 |
> deprecated in the EAPI 3 to 4 jump. |
29 |
|
30 |
Good point, we should probably split this up in multiple phases: |
31 |
|
32 |
1) Repoman warns about deprecation of ebuilds with older EAPI. |
33 |
|
34 |
2) Repoman bails out on the addition of _new_ ebuilds with older EAPI. |
35 |
|
36 |
3) Repoman bails out on changes to _existing_ ebuilds with older EAPI. |
37 |
|
38 |
As a side note, we'll need to implement VCS diff support in repoman to |
39 |
check for this; as currently you can only check based the ebuilds. |
40 |
Nevertheless a hack is possible, but I think we should avoid that... |
41 |
|
42 |
-- |
43 |
With kind regards, |
44 |
|
45 |
Tom Wijsman (TomWij) |
46 |
Gentoo Developer |
47 |
|
48 |
E-mail address : TomWij@g.o |
49 |
GPG Public Key : 6D34E57D |
50 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |