| 1 |
Patrick Lauer wrote: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you |
| 5 |
> count them ;) ) EAPIs available or almost available. This is getting quite |
| 6 |
> confusing. |
| 7 |
> To make our lives easier I would suggest deprecating EAPI0 and migrating |
| 8 |
> existing ebuilds over some time to EAPI1 or higher until EAPI0 can be |
| 9 |
> obsoleted at some point in the future. |
| 10 |
> I would set the start of deprecation warnings about 3 months from now and the |
| 11 |
> obsoletion quite a time later, maybe 12 months from now, when a sufficient |
| 12 |
> amount of ebuilds has been migrated. |
| 13 |
> |
| 14 |
> Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to |
| 15 |
> think about, but since it has some changes like adding src_prepare migration |
| 16 |
> would not be as trivial. So I'd prefer keeping it around a bit longer. |
| 17 |
> |
| 18 |
> Comments? |
| 19 |
> |
| 20 |
> |
| 21 |
> Patrick |
| 22 |
> |
| 23 |
|
| 24 |
While there definitely arguments for deprecating EAPIs, I would suggest |
| 25 |
caution. |
| 26 |
|
| 27 |
A low number of active EAPIs can make life easier for developers, but it |
| 28 |
can also make life harder for some users. There are still users coming |
| 29 |
to the forums upgrading systems which only understand EAPI 0. I accept |
| 30 |
that Gentoo is certainly a relatively fast moving distro, but I think |
| 31 |
that developers also do need to consider users who have systems that are |
| 32 |
currently "just working" and may not upgrade often (once a year or even |
| 33 |
less). |
| 34 |
|
| 35 |
As such, I would suggest that forcing a move to the most recent stable |
| 36 |
EAPI is possibly unwise. |
| 37 |
|
| 38 |
I believe that forcing EAPIs to move forward at too quick a pace will |
| 39 |
cause more issues for these users. An answer to this could be to set a |
| 40 |
standard for the minimum time between upgrades - for example, 1 year - |
| 41 |
and ensure that users with anything that old can atleast upgrade portage |
| 42 |
and its dependencies to the minimum required versions without major issues. |
| 43 |
|
| 44 |
I understand that this may cause extra work in some respects, but if |
| 45 |
such a standard is set and documented then it will help users (admins) |
| 46 |
by giving them a set frequency at which they must upgrade at least the |
| 47 |
package manager, if not @system. |
| 48 |
|
| 49 |
|
| 50 |
Secondly, it was suggested that a project to upgrade all ebuilds in the |
| 51 |
tree from EAPI 0 could bring new developers, offering KDE4 as an |
| 52 |
example. I would offer caution on this assumption. KDE4 was not simply |
| 53 |
about upgrading ebuilds, but about users (contributors) and developers |
| 54 |
being able to install and test packages they wanted to install and test. |
| 55 |
I can not realistically see such an effort being asserted in the name of |
| 56 |
simply deprecating EAPIs. |
| 57 |
|
| 58 |
Yes, breakage occurred, but this was as far as I can see a complete |
| 59 |
rewrite of the KDE packaging from scratch. As such I would suggest that |
| 60 |
a certain level of breakage was to be expected. I would also suggest |
| 61 |
that the speed at which bugs are being fixed may be more of an indicator |
| 62 |
of lack of man power than anything else, and that the situation could be |
| 63 |
improved by looking at expending more effort on encouraging |
| 64 |
contributions and ultimately recruiting developers. I realize that |
| 65 |
getting people to expend effort on non-coding work can be difficult, but |
| 66 |
I think that ultimately the effort expended will be repaid in terms of |
| 67 |
extra contributions. |
| 68 |
|
| 69 |
|
| 70 |
In general, I would have to agree with those who believe there are |
| 71 |
currently better ways to expend effort within Gentoo. As such I would |
| 72 |
suggest that at most, EAPI deprecation only applies to new packages and |
| 73 |
version bumps. |
| 74 |
|
| 75 |
AllenJB |
Archives