Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Andreas K. Huettel]

> > 
> > * Mainly, less stuff to memorize. I'll be throwing a party on the day when
> > the last EAPI=0 ebuild is gone. (In the retirement home, probably.)
> 
> This is the argument made by others about the cognitive overhead of
> remembering all the EAPI differences. If the packages are untouched
> for ages and don't require maintenance, my claim is that there is no
> cognitive load to begin with.

That stops the moment something could use a USE- or slot operator dependency 
(because of a tree-wide change that also affects the old package). Then the 
EAPI bump suddenly becomes urgent (and a minor QA-like commit becomes a major 
change).

And no bugs probably just means no users that could file bugs. We really need 
something like gentoostats...

> > [Interestingly, as long as no specific efforts are made, the number of
> > ebuilds in all deprecated EAPI decreases roughly equally and
> > exponentially. That means the probability of any old ebuild to be removed
> > within a certain time interval is a constant as function of time...]
> 
> This is a great point in favor of *not* bothering to proactively bump EAPI.

Not really. It's an asymptotic curve. *If* you want to have it gone 
*completely* at some point, you have to start actively working on that. The 
only question is when, earlier or later... 

I'd guess having an EAPI approach <~ 1% of the tree is probably as good as any 
other criterion.

[[What is interesting but offtopic is that the exponential decay is the same 
for a long timeframe, see [*] third panel... the downward slope of the white 
line for EAPI=0 barely changes, and the other EAPI run parallel to it as long 
as nothing special happens... This means that Gentoo isn't dying after all, 
since the same developer activity takes place!]]

[*] https://www.akhuettel.de/~huettel/plots/eapi.php

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Rich Freeman]

On Tue, Mar 6, 2018 at 6:39 PM, Matt Turner  wrote:
> On Tue, Mar 6, 2018 at 2:27 PM, Alec Warner  wrote:
>> On Tue, Mar 6, 2018 at 5:22 PM, Matt Turner  wrote:
>>> On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman  wrote:
>>> > On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel
>>> >  wrote:
>>> >>
>>> >> Is it worth the effort? Yes, see below.
>>> >> Is it a high priority task? No.
>>> >>
>>> >
>>> > It sounds like all that has been done is to log a tracker and create
>>> > some bugs.  That is hardly a major burden on anybody.  If it nudges
>>> > people to bump the EAPI when they're doing other work so much the
>>> > better, but there doesn't seem to be a drop-dead date yet.
>>> >
>>> > If devs don't want to think about EAPI cleanup they don't have to right
>>> > now.
>>>
>>> No, not true. Look at the blocking bugs. We're asking arch teams to
>>> retest and restabilize ebuilds whose only difference is the EAPI bump.
>>>
>>
>> Ultimate the arch teams are supposed to test the ebuild (that it works), so
>> when we change the EAPI of the ebuild re-testing is required.
>
> Of course, but that's not the point...
>

Strictly speaking nobody is forcing the arch teams to test any of
these bumps either.  They are as free to choose to work on those bugs
as anybody else.

-- 
Rich

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 2:27 PM, Alec Warner  wrote:
> On Tue, Mar 6, 2018 at 5:22 PM, Matt Turner  wrote:
>> On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman  wrote:
>> > On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel
>> >  wrote:
>> >>
>> >> Is it worth the effort? Yes, see below.
>> >> Is it a high priority task? No.
>> >>
>> >
>> > It sounds like all that has been done is to log a tracker and create
>> > some bugs.  That is hardly a major burden on anybody.  If it nudges
>> > people to bump the EAPI when they're doing other work so much the
>> > better, but there doesn't seem to be a drop-dead date yet.
>> >
>> > If devs don't want to think about EAPI cleanup they don't have to right
>> > now.
>>
>> No, not true. Look at the blocking bugs. We're asking arch teams to
>> retest and restabilize ebuilds whose only difference is the EAPI bump.
>>
>
> Ultimate the arch teams are supposed to test the ebuild (that it works), so
> when we change the EAPI of the ebuild re-testing is required.

Of course, but that's not the point...

Re: [gentoo-dev] dev-db/maxscale - Last rites

[Brian Evans]

On 03/06/2018 05:55 PM, Geaaru wrote:
> Hi,
> 
> I'm not sure that comment of the issue is yet correct with last version.
> I think that depends of mariadb libraries and maybe it works also with
> mysql but I will investigate on it.
> 
> Here (not last version but at least v.2.x):
> 
> https://github.com/geaaru/geaaru_overlay/blob/master/dev-db/maxscale/maxscale-2.1.5.ebuild
> 
> An error on my ebuild is that now license is BSL but I can fix fast this.
> 
> I try to check compilation with last gcc version and push a pr to gentoo
> upstream it you agree and try to get package as proxy mantainer.
> 
> My cent
> G.
> 
> On Mar 6, 2018 6:33 PM, "Brian Evans"  > wrote:
> 
> # Brian Evans mailto:grkni...@gentoo.org>> (06
> Mar 2018)
> # MariaDB MaxScale 1.x depends on the deprecated libmysqld
> # Newer versions bundle software that require git access
> # and modify system libraries for their own purposes making
> # it extremely difficult to package.
> # Bug 649764 Removal in 30 days.
> dev-db/maxscale
> 

As it sits, Line 27 of your ebuild is not acceptable,
virtual/mysql[embedded] is going away.

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-db/maxscale - Last rites

[Geaaru]

Hi,

I'm not sure that comment of the issue is yet correct with last version.
I think that depends of mariadb libraries and maybe it works also with
mysql but I will investigate on it.

Here (not last version but at least v.2.x):

https://github.com/geaaru/geaaru_overlay/blob/master/dev-db/maxscale/maxscale-2.1.5.ebuild

An error on my ebuild is that now license is BSL but I can fix fast this.

I try to check compilation with last gcc version and push a pr to gentoo
upstream it you agree and try to get package as proxy mantainer.

My cent
G.

On Mar 6, 2018 6:33 PM, "Brian Evans"  wrote:

> # Brian Evans  (06 Mar 2018)
> # MariaDB MaxScale 1.x depends on the deprecated libmysqld
> # Newer versions bundle software that require git access
> # and modify system libraries for their own purposes making
> # it extremely difficult to package.
> # Bug 649764 Removal in 30 days.
> dev-db/maxscale
>
>

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Alec Warner]

On Tue, Mar 6, 2018 at 5:22 PM, Matt Turner  wrote:

> On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman  wrote:
> > On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel 
> wrote:
> >>
> >> Is it worth the effort? Yes, see below.
> >> Is it a high priority task? No.
> >>
> >
> > It sounds like all that has been done is to log a tracker and create
> > some bugs.  That is hardly a major burden on anybody.  If it nudges
> > people to bump the EAPI when they're doing other work so much the
> > better, but there doesn't seem to be a drop-dead date yet.
> >
> > If devs don't want to think about EAPI cleanup they don't have to right
> now.
>
> No, not true. Look at the blocking bugs. We're asking arch teams to
> retest and restabilize ebuilds whose only difference is the EAPI bump.
>
>
Ultimate the arch teams are supposed to test the ebuild (that it works), so
when we change the EAPI of the ebuild re-testing is required.
If we only cared about the ebuild (that it worked or not) we could use
automation to cut down on the humans involved in this work.

-A

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman  wrote:
> On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel  
> wrote:
>>
>> Is it worth the effort? Yes, see below.
>> Is it a high priority task? No.
>>
>
> It sounds like all that has been done is to log a tracker and create
> some bugs.  That is hardly a major burden on anybody.  If it nudges
> people to bump the EAPI when they're doing other work so much the
> better, but there doesn't seem to be a drop-dead date yet.
>
> If devs don't want to think about EAPI cleanup they don't have to right now.

No, not true. Look at the blocking bugs. We're asking arch teams to
retest and restabilize ebuilds whose only difference is the EAPI bump.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 1:17 PM, Andreas K. Huettel  wrote:
> Am Dienstag, 6. März 2018, 02:52:54 CET schrieb Matt Turner:
>> EAPI 2 removal bug: https://bugs.gentoo.org/648050
>>
>> It seems like tons of churn to update old stable ebuilds to a new
>> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for
>> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise
>> functionally identical. Now asking arch teams to retest and
>> restabilize. Multiply by 100 or more.
>
> OK so here's my personal opinion:
>
> Is it worth the effort? Yes, see below.
> Is it a high priority task? No.
>
> Is it really that much effort? Well, we're even in the case of EAPI=2 talking
> about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. And
> I'd strongly suspect that even without the EAPI update it would make very much
> sense to check these 400 old ebuilds and test whether they still work as
> intended.

There are plenty of reported bugs to look at. No need to go searching
for more :)

> What do we gain?
>
> * Mainly, less stuff to memorize. I'll be throwing a party on the day when the
> last EAPI=0 ebuild is gone. (In the retirement home, probably.)

This is the argument made by others about the cognitive overhead of
remembering all the EAPI differences. If the packages are untouched
for ages and don't require maintenance, my claim is that there is no
cognitive load to begin with.

> * Also, it's not just having a bigger number, but also useful features...
>
> Why now EAPI=2?
>
> * EAPI=3 is nearly gone (27 ebuilds left, scheme & java please get a move! :)
> * EAPI=2 is the one with the next-least ebuilds.
>
> While it would be very nice to remove EAPI=0, let's go for easier targets
> first; the number of EAPI=0 ebuilds will decrease organically in the meantime.
>
> [Interestingly, as long as no specific efforts are made, the number of ebuilds
> in all deprecated EAPI decreases roughly equally and exponentially. That means
> the probability of any old ebuild to be removed within a certain time interval
> is a constant as function of time...]

This is a great point in favor of *not* bothering to proactively bump EAPI.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 1:00 AM, Dirkjan Ochtman  wrote:
> On Tue, Mar 6, 2018 at 2:52 AM, Matt Turner  wrote:
>>
>> In the end we might get to delete some code from portage or an eclass?
>> Does this seem worth it?
>
>
> To add to some of the points Kent made, I think so, yes: this means freeing
> us from the cognitive overhead of thinking about older EAPIs at all, having
> to remember the differences between those old EAPIs and the newer ones.
> Removing that complexity from developer's minds as well as from our tooling
> means our tooling will be we can spend our time and energy on other things,
> which will be a win for the distribution.
>
> Yes, the long tail is painful: these are probably the packages that haven't
> been upgraded before for a reason, but actually putting the finishing
> touches on the EAPI migration will be worth it in the end.

The long tail of packages were packages that by definition didn't
require any maintenance or add to our collective cognitive overhead.
:)

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Mon, Mar 5, 2018 at 9:56 PM, Kent Fredric  wrote:
> On Mon, 5 Mar 2018 17:52:54 -0800
> And with Perl packages at least, incrementing EAPI results in actual
> changes driven by the eclass:
>
> - Changes the names of various control variables
> - Makes perl tests on by default, and parallel by default ( previously
>   required opt-in )
> - Disables the legacy code path that kills the '.packlist' files, which
>   are actually useful to some tools, and was the wrong place to kill
>   those files in the first place.

Sounds like you're not bumping EAPI for its own sake.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Rich Freeman]

On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel  wrote:
>
> Is it worth the effort? Yes, see below.
> Is it a high priority task? No.
>

It sounds like all that has been done is to log a tracker and create
some bugs.  That is hardly a major burden on anybody.  If it nudges
people to bump the EAPI when they're doing other work so much the
better, but there doesn't seem to be a drop-dead date yet.

If devs don't want to think about EAPI cleanup they don't have to right now.

The delta as you get to more recent EAPIs hasn't been quite as extreme
as in the early ones, so this should hopefully become simpler as we go
along...

-- 
Rich

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Andreas K. Huettel]

Am Dienstag, 6. März 2018, 02:52:54 CET schrieb Matt Turner:
> EAPI 2 removal bug: https://bugs.gentoo.org/648050
> 
> It seems like tons of churn to update old stable ebuilds to a new
> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for
> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise
> functionally identical. Now asking arch teams to retest and
> restabilize. Multiply by 100 or more.

OK so here's my personal opinion: 

Is it worth the effort? Yes, see below.
Is it a high priority task? No.

Is it really that much effort? Well, we're even in the case of EAPI=2 talking 
about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. And 
I'd strongly suspect that even without the EAPI update it would make very much 
sense to check these 400 old ebuilds and test whether they still work as 
intended. 

What do we gain? 

* Mainly, less stuff to memorize. I'll be throwing a party on the day when the 
last EAPI=0 ebuild is gone. (In the retirement home, probably.)

* Also, it's not just having a bigger number, but also useful features...

Why now EAPI=2? 

* EAPI=3 is nearly gone (27 ebuilds left, scheme & java please get a move! :)
* EAPI=2 is the one with the next-least ebuilds.

While it would be very nice to remove EAPI=0, let's go for easier targets 
first; the number of EAPI=0 ebuilds will decrease organically in the meantime.

[Interestingly, as long as no specific efforts are made, the number of ebuilds 
in all deprecated EAPI decreases roughly equally and exponentially. That means
the probability of any old ebuild to be removed within a certain time interval 
is a constant as function of time...]

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] [PATCH 1/6] eapi7-ver.eclass: Explicitly indicate that EAPI 7+ includes it

[Michael Orlitzky]

On 03/06/2018 12:25 PM, Michał Górny wrote:
> ---
>  eclass/eapi7-ver.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/eapi7-ver.eclass b/eclass/eapi7-ver.eclass
> index 7eb070c68171..6117124a90a5 100644
> --- a/eclass/eapi7-ver.eclass
> +++ b/eclass/eapi7-ver.eclass
> @@ -63,7 +63,7 @@ case ${EAPI:-0} in
>   6)
>   ;;
>   *)
> - die "${ECLASS}: EAPI=${EAPI} unknown";;
> + die "${ECLASS}: EAPI=${EAPI} includes all functions from this 
> eclass";;
>  esac
>  

That error message might be a lie; think exheres-0. I think you can put
the "6" case first, and then change the "0|1|2|3|4|5" case to "*" to
have all others die with "not supported".

Re: [gentoo-dev] [PATCH 3/6] epatch.eclass: Deprecate in EAPI 6

[Ulrich Mueller]

> On Tue, 06 Mar 2018, Michał Górny wrote:

> W dniu wto, 06.03.2018 o godzinie 18∶41 +0100, użytkownik Ulrich Mueller
> napisał:
>> > > > > > On Tue, 6 Mar 2018, Michał Górny wrote:
>> > +  6)
>> > +  # for eqawarn
>> > +  [[ -z ${_EUTILS_ECLASS} ]] && inherit eutils
>> >;;
>> 
>> NACK. With this you defeat the whole purpose of splitting things
>> off from eutils. In turn, eutils inherits a dozen of other eclasses
>> in EAPI 6. (Same for ltprune.eclass in patch 5/6.)

> Yeah, you have a point there. Time to split eqawarn into its own
> eclass? ;-)

One-line eclass? :)

No, I suggest to omit the deprecation part. With more than half of
the tree at EAPI 6 already, it would be pretty late for deprecation
warnings to be added for that EAPI. So simply do a clear-cut change
for EAPI 7.

Ulrich


pgpjzR_a63sC6.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH 3/6] epatch.eclass: Deprecate in EAPI 6

[Michał Górny]

W dniu wto, 06.03.2018 o godzinie 18∶41 +0100, użytkownik Ulrich Mueller
napisał:
> > > > > > On Tue, 6 Mar 2018, Michał Górny wrote:
> > +   6)
> > +   # for eqawarn
> > +   [[ -z ${_EUTILS_ECLASS} ]] && inherit eutils
> > ;;
> 
> NACK. With this you defeat the whole purpose of splitting things off
> from eutils. In turn, eutils inherits a dozen of other eclasses in
> EAPI 6. (Same for ltprune.eclass in patch 5/6.)

Yeah, you have a point there. Time to split eqawarn into its own eclass?
;-)

> Also _EUTILS_ECLASS is an internal variable of eutils and should not
> be accessed outside of it.
> 
> Ulrich

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH 3/6] epatch.eclass: Deprecate in EAPI 6

[Ulrich Mueller]

> On Tue, 6 Mar 2018, Michał Górny wrote:

> + 6)
> + # for eqawarn
> + [[ -z ${_EUTILS_ECLASS} ]] && inherit eutils
>   ;;

NACK. With this you defeat the whole purpose of splitting things off
from eutils. In turn, eutils inherits a dozen of other eclasses in
EAPI 6. (Same for ltprune.eclass in patch 5/6.)

Also _EUTILS_ECLASS is an internal variable of eutils and should not
be accessed outside of it.

Ulrich


pgp3PTz9_3Fgt.pgp
Description: PGP signature

[gentoo-dev] dev-db/maxscale - Last rites

[Brian Evans]

# Brian Evans  (06 Mar 2018)
# MariaDB MaxScale 1.x depends on the deprecated libmysqld
# Newer versions bundle software that require git access
# and modify system libraries for their own purposes making
# it extremely difficult to package.
# Bug 649764 Removal in 30 days.
dev-db/maxscale



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 6/6] versionator.eclass: Ban in EAPI 7 (in favor of built-in funcs)

[Michał Górny]

---
 eclass/versionator.eclass | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/eclass/versionator.eclass b/eclass/versionator.eclass
index 54d77a30b015..bf3f6a2a77b6 100644
--- a/eclass/versionator.eclass
+++ b/eclass/versionator.eclass
@@ -28,6 +28,13 @@
 if [[ -z ${_VERSIONATOR_ECLASS} ]]; then
 _VERSIONATOR_ECLASS=1
 
+case ${EAPI:-0} in
+   0|1|2|3|4|5|6)
+   ;;
+   *)
+   die "${ECLASS}: banned in EAPI=${EAPI}; use ver_* instead";;
+esac
+
 inherit estack
 
 # @FUNCTION: get_all_version_components
-- 
2.16.2

[gentoo-dev] [PATCH 5/6] ltprune.eclass: Deprecate it verbosely

[Michał Górny]

---
 eclass/ltprune.eclass | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/eclass/ltprune.eclass b/eclass/ltprune.eclass
index a8bb4c842bc0..f1dd795aea2a 100644
--- a/eclass/ltprune.eclass
+++ b/eclass/ltprune.eclass
@@ -17,6 +17,8 @@ if [[ -z ${_LTPRUNE_ECLASS} ]]; then
 
 case ${EAPI:-0} in
0|1|2|3|4|5|6)
+   # for eqawarn
+   [[ -z ${_EUTILS_ECLASS} ]] && inherit eutils
;;
*)
die "${ECLASS}: banned in EAPI=${EAPI}; use 'find' instead";;
@@ -52,6 +54,11 @@ inherit toolchain-funcs
 prune_libtool_files() {
debug-print-function ${FUNCNAME} "$@"
 
+   eqawarn "prune_libtool_files is deprecated. Please use the following 
one-liner"
+   eqawarn "instead:"
+   eqawarn
+   eqawarn "  find "${D}" -name '*.la' -delete || die"
+
local removing_all removing_modules opt
for opt; do
case "${opt}" in
-- 
2.16.2

[gentoo-dev] [PATCH 3/6] epatch.eclass: Deprecate in EAPI 6

[Michał Górny]

---
 eclass/epatch.eclass | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
index 8e03478c26ce..e3178ff40020 100644
--- a/eclass/epatch.eclass
+++ b/eclass/epatch.eclass
@@ -12,7 +12,11 @@
 if [[ -z ${_EPATCH_ECLASS} ]]; then
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6)
+   0|1|2|3|4|5)
+   ;;
+   6)
+   # for eqawarn
+   [[ -z ${_EUTILS_ECLASS} ]] && inherit eutils
;;
*)
die "${ECLASS}: banned in EAPI=${EAPI}; use eapply* instead";;
@@ -103,6 +107,10 @@ EPATCH_FORCE="no"
 #
 # Refer to the other EPATCH_xxx variables for more customization of behavior.
 epatch() {
+   if [[ ${EAPI} == 6 ]]; then
+   eqawarn "epatch function is deprecated in EAPI ${EAPI}. Please 
use eapply instead."
+   fi
+
_epatch_draw_line() {
# create a line of same length as input string
[[ -z $1 ]] && set "$(printf "%65s" '')"
-- 
2.16.2

[gentoo-dev] [PATCH 4/6] ltprune.eclass: Ban discouraged eclass in EAPI 7

[Michał Górny]

---
 eclass/ltprune.eclass | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/eclass/ltprune.eclass b/eclass/ltprune.eclass
index 6b3e93921d96..a8bb4c842bc0 100644
--- a/eclass/ltprune.eclass
+++ b/eclass/ltprune.eclass
@@ -15,6 +15,13 @@
 
 if [[ -z ${_LTPRUNE_ECLASS} ]]; then
 
+case ${EAPI:-0} in
+   0|1|2|3|4|5|6)
+   ;;
+   *)
+   die "${ECLASS}: banned in EAPI=${EAPI}; use 'find' instead";;
+esac
+
 inherit toolchain-funcs
 
 # @FUNCTION: prune_libtool_files
-- 
2.16.2

[gentoo-dev] [PATCH 2/6] epatch.eclass: Ban in EAPI 7 (in favor of eapply)

[Michał Górny]

---
 eclass/epatch.eclass | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/eclass/epatch.eclass b/eclass/epatch.eclass
index 905f68f8ef22..8e03478c26ce 100644
--- a/eclass/epatch.eclass
+++ b/eclass/epatch.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: epatch.eclass
@@ -11,6 +11,13 @@
 
 if [[ -z ${_EPATCH_ECLASS} ]]; then
 
+case ${EAPI:-0} in
+   0|1|2|3|4|5|6)
+   ;;
+   *)
+   die "${ECLASS}: banned in EAPI=${EAPI}; use eapply* instead";;
+esac
+
 inherit estack
 
 # @VARIABLE: EPATCH_SOURCE
-- 
2.16.2

[gentoo-dev] [PATCH 1/6] eapi7-ver.eclass: Explicitly indicate that EAPI 7+ includes it

[Michał Górny]

---
 eclass/eapi7-ver.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/eapi7-ver.eclass b/eclass/eapi7-ver.eclass
index 7eb070c68171..6117124a90a5 100644
--- a/eclass/eapi7-ver.eclass
+++ b/eclass/eapi7-ver.eclass
@@ -63,7 +63,7 @@ case ${EAPI:-0} in
6)
;;
*)
-   die "${ECLASS}: EAPI=${EAPI} unknown";;
+   die "${ECLASS}: EAPI=${EAPI} includes all functions from this 
eclass";;
 esac
 
 # @FUNCTION: _ver_parse_range
-- 
2.16.2

[gentoo-dev] [PATCH 0/6] EAPI 7 eclass deprecations

[Michał Górny]

Hi,

Here's a short batch of patches that explicitly update EAPI checks
for eclass that are going to be banned in EAPI 7, and add some verbose
deprecation notices whenever stuff was deprecated already.

--
Best regards,
Michał Górny

Michał Górny (6):
  eapi7-ver.eclass: Explicitly indicate that EAPI 7+ includes it
  epatch.eclass: Ban in EAPI 7 (in favor of eapply)
  epatch.eclass: Deprecate in EAPI 6
  ltprune.eclass: Ban discouraged eclass in EAPI 7
  ltprune.eclass: Deprecate it verbosely
  versionator.eclass: Ban in EAPI 7 (in favor of built-in funcs)

 eclass/eapi7-ver.eclass   |  2 +-
 eclass/epatch.eclass  | 17 -
 eclass/ltprune.eclass | 14 ++
 eclass/versionator.eclass |  7 +++
 4 files changed, 38 insertions(+), 2 deletions(-)

-- 
2.16.2

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Michał Górny]

W dniu pon, 05.03.2018 o godzinie 17∶52 -0800, użytkownik Matt Turner
napisał:
> EAPI 2 removal bug: https://bugs.gentoo.org/648050
> 
> It seems like tons of churn to update old stable ebuilds to a new
> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for
> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise
> functionally identical. Now asking arch teams to retest and
> restabilize. Multiply by 100 or more.
> 
> In the end we might get to delete some code from portage or an eclass?
> Does this seem worth it?

Removing any code from package managers is unlikely, so that is not
an argument.

Removing code from eclasses is actually beneficial. Please remember that
EAPI changes are not isolated to the PMS, and eclasses also use them to
kill deprecated features and make other breaking changes.

Both PMS and eclasses add new features in new EAPIs. Others have already
bought some examples. To examples others have already mentioned you
could add new econf options [1]. As a result, bumping EAPI frequently
*improves* the quality of the package and sometimes fixes bugs (reported
or unreported).

Most importantly, killing old EAPIs makes Gentoo easier for
contributors. You may think it's normal to expect Gentoo developers
to know 7 EAPIs and the differences between them. It might be normal for
people who are around long enough to see most of them.
But e.g. in proxy-maint we don't want to teach people about 7 EAPIs
if only 1 or 2 of them are really relevant to what they're doing.

Finally, old EAPIs are simply more prone to mistakes. When the majority
of 'current' Gentoo packages, i.e. the packages Gentoo developers
usually touch, use new EAPIs, it is *really easy* to miss that some old
package is using an ancient EAPI and start scratching your head why
something does not work.

Killing old EAPIs proactively -- like many other proactive efforts --
has the advantage of making the work of others easier. If I end up
having to fix a dozen old packages because of some reverse dependency,
I'd really find it preferable that someone already did the EAPI bump for
me and I wouldn't have to focus at the same time on fixing some issue,
bumping EAPI, fixing tests and doing all the other long-overdue
maintenance tasks.

[1]:https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-13700012.3.8

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Dirkjan Ochtman]

On Tue, Mar 6, 2018 at 2:52 AM, Matt Turner  wrote:

> In the end we might get to delete some code from portage or an eclass?
> Does this seem worth it?
>

To add to some of the points Kent made, I think so, yes: this means freeing
us from the cognitive overhead of thinking about older EAPIs at all, having
to remember the differences between those old EAPIs and the newer ones.
Removing that complexity from developer's minds as well as from our tooling
means our tooling will be we can spend our time and energy on other things,
which will be a win for the distribution.

Yes, the long tail is painful: these are probably the packages that haven't
been upgraded before for a reason, but actually putting the finishing
touches on the EAPI migration will be worth it in the end.

It might have been even better if Andreas or someone else had announced
this project/discussed the trade-offs before starting it.

Cheers,

Dirkjan

[gentoo-dev] Packages up for grabs: dev-libs/libtar

[Jonas Stein]

Dear all,

The following packages are up for grabs:

dev-libs/libtar

after retirement of the proxied maintainer.
https://packages.gentoo.org/packages/dev-libs/libtar

libtar is a C library for manipulating tar archives.

Todo: please migrate from 'autotools-utils' (no replacement)

-- 
Best,
Jonas











































signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grabs: app-editors/bluefish

[Jonas Stein]

Dear all,

The following packages are up for grabs:

app-editors/bluefish

after retirement of the proxied maintainer.
https://packages.gentoo.org/packages/app-editors/bluefish

The editor is quite famous and it would be nice to keep the ebuild in a
good state.

Todo: please migrate from 'fdo-mime' to 'xdg-utils'

-- 
Best,
Jonas









































signature.asc
Description: OpenPGP digital signature