[gentoo-dev] [PATCH 1/3] xorg-2.eclass: Drop support for EAPI 3

[gentoo-dev] [PATCH 1/3] xorg-2.eclass: Drop support for EAPI 3

[Matt Turner]

No ebuilds inheriting xorg-2 are EAPI=3.
---
 eclass/xorg-2.eclass | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 4ed65e676a0..7133aa365f1 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Author: Tomáš Chvátal <scarabeus@gentoo.org>
 # Author: Donnie Berkholz <dberkholz@gentoo.org>
-# @SUPPORTED_EAPIS: 3 4 5
+# @SUPPORTED_EAPIS: 4 5
 # @BLURB: Reduces code duplication in the modularized X11 ebuilds.
 # @DESCRIPTION:
 # This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -53,7 +53,7 @@ fi
 
 EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
 case "${EAPI:-0}" in
-	3|4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare src_configure" ;;
+	4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare src_configure" ;;
 	*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
@@ -271,7 +271,7 @@ fi
 
 if [[ ${XORG_MODULE_REBUILD} == yes ]]; then
 	case ${EAPI} in
-		3|4)
+		4)
 			;;
 		*)
 			RDEPEND+=" x11-base/xorg-server:="
@@ -530,7 +530,7 @@ xorg-2_pkg_postrm() {
 
 	if [[ -n ${FONT} ]]; then
 		# if we're doing an upgrade, postinst will do
-		if [[ ${EAPI} -lt 4 || -z ${REPLACED_BY_VERSION} ]]; then
+		if [[ -z ${REPLACED_BY_VERSION} ]]; then
 			create_fonts_scale
 			create_fonts_dir
 			font_pkg_postrm "$@"
-- 
2.19.2

[gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

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

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 7133aa365f1..74660e7f213 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -500,7 +500,7 @@ xorg-2_src_install() {
 	fi
 
 	# Don't install libtool archives (even for modules)
-	prune_libtool_files --all
+	find "${D}" -name '*.la' -delete || die
 
 	[[ -n ${FONT} ]] && remove_font_metadata
 }
-- 
2.19.2

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
 
>  	# Don't install libtool archives (even for modules)
> -	prune_libtool_files --all
> +	find "${D}" -name '*.la' -delete || die

Maybe restrict removal to regular files, i.e. add "-type f"?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

On Tue, Feb 19, 2019 at 10:21 PM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>
> >       # Don't install libtool archives (even for modules)
> > -     prune_libtool_files --all
> > +     find "${D}" -name '*.la' -delete || die
>
> Maybe restrict removal to regular files, i.e. add "-type f"?

Is that ever a problem? The 'find ...' that I replaced
prune_libtool_files is a verbatim copy of what ltprune.eclass says to
use instead:

# Discouraged. Whenever possible, please use much simpler:
# @CODE
# find "${D}" -name '*.la' -delete || die
# @CODE

grepping the repo, I think a strong case can be made in favor of
ltprune.eclass given the wide variety of ways this is open coded...

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> 
>  
> >  	# Don't install libtool archives (even for modules)
> > -	prune_libtool_files --all
> > +	find "${D}" -name '*.la' -delete || die
> 
> Maybe restrict removal to regular files, i.e. add "-type f"?

I suppose you should have spoken up when people started adopting that
'find' line all over the place.  Though I honestly doubt we're going to
see many packages installing '*.la' non-files.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

>>>>> On Wed, 20 Feb 2019, Michał Górny wrote:

> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
>> 
>> 
>> >  	# Don't install libtool archives (even for modules)
>> > -	prune_libtool_files --all
>> > +	find "${D}" -name '*.la' -delete || die
>> 
>> Maybe restrict removal to regular files, i.e. add "-type f"?

> I suppose you should have spoken up when people started adopting that
> 'find' line all over the place.  Though I honestly doubt we're going to
> see many packages installing '*.la' non-files.

Indeed, non-libtool *.la files are more likely. I vaguely remember
a package trying to install A-law sound files of that name.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[desultory]

On 02/20/19 02:36, Michał Górny wrote:
> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>
>>  
>>>  	# Don't install libtool archives (even for modules)
>>> -	prune_libtool_files --all
>>> +	find "${D}" -name '*.la' -delete || die
>>
>> Maybe restrict removal to regular files, i.e. add "-type f"?
> 
> I suppose you should have spoken up when people started adopting that
> 'find' line all over the place.  Though I honestly doubt we're going to
> see many packages installing '*.la' non-files.
> 
Just so we are all clear here: your argument is that more fully correct
approaches should not be considered in the present and future because
less fully correct approaches were implemented in the past? And,
further, that since nothing matching a specific pattern happens to come
to your mind at he moment, such things do not exist? Perhaps dialing
back the rhetoric from 11 and considering feedback as an opportunity to
improve existing code is called for in this case, among others.

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Fri, 22 Feb 2019 23:30:15 -0500 desultory wrote:
> On 02/20/19 02:36, Michał Górny wrote:
> > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> >>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >>
> >>  
> >>>  	# Don't install libtool archives (even for modules)
> >>> -	prune_libtool_files --all
> >>> +	find "${D}" -name '*.la' -delete || die
> >>
> >> Maybe restrict removal to regular files, i.e. add "-type f"?
> > 
> > I suppose you should have spoken up when people started adopting that
> > 'find' line all over the place.  Though I honestly doubt we're going to
> > see many packages installing '*.la' non-files.
> > 
> Just so we are all clear here: your argument is that more fully correct
> approaches should not be considered in the present and future because
> less fully correct approaches were implemented in the past? And,
> further, that since nothing matching a specific pattern happens to come
> to your mind at he moment, such things do not exist? Perhaps dialing
> back the rhetoric from 11 and considering feedback as an opportunity to
> improve existing code is called for in this case, among others.

If we are going to improve code, we should also use find -O3. 


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[desultory]

On 02/23/19 03:42, Andrew Savchenko wrote:
> On Fri, 22 Feb 2019 23:30:15 -0500 desultory wrote:
>> On 02/20/19 02:36, Michał Górny wrote:
>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>>>
>>>>  
>>>>>  	# Don't install libtool archives (even for modules)
>>>>> -	prune_libtool_files --all
>>>>> +	find "${D}" -name '*.la' -delete || die
>>>>
>>>> Maybe restrict removal to regular files, i.e. add "-type f"?
>>>
>>> I suppose you should have spoken up when people started adopting that
>>> 'find' line all over the place.  Though I honestly doubt we're going to
>>> see many packages installing '*.la' non-files.
>>>
>> Just so we are all clear here: your argument is that more fully correct
>> approaches should not be considered in the present and future because
>> less fully correct approaches were implemented in the past? And,
>> further, that since nothing matching a specific pattern happens to come
>> to your mind at he moment, such things do not exist? Perhaps dialing
>> back the rhetoric from 11 and considering feedback as an opportunity to
>> improve existing code is called for in this case, among others.
> 
> If we are going to improve code, we should also use find -O3. 
> 
Please forgive my presumption, but I am going to infer that your comment
was neither meant to display gross ignorance of find (1) nor as a
strawman, but was instead merely a joke; and on that basis ask you a
question.

Why, in your opinion, should it be acceptable for a member of QA to
dismiss commentary on a piece of code on grounds that he knows to be
spurious? Especially code that has been noted, in this very thread, to
encounter cases where it does the wrong thing. Especially when the
proposed change actually removes a class of potential misbehavior of the
code in question.

The proposed change hardly appears to be difficult to implement,
difficult to maintain, expansive in scale, or obscure in nature; so none
of those concerns would appear to apply. Though it does miss at least
one obvious class of potential misbehavior, but that was not the basis
on which it was dismissed.

I eagerly await your insight.

> 
> Best regards,
> Andrew Savchenko
> 

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

On Fri, Feb 22, 2019 at 8:30 PM desultory <desultory@gentoo.org> wrote:
>
> On 02/20/19 02:36, Michał Górny wrote:
> > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> >>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >>
> >>
> >>>     # Don't install libtool archives (even for modules)
> >>> -   prune_libtool_files --all
> >>> +   find "${D}" -name '*.la' -delete || die
> >>
> >> Maybe restrict removal to regular files, i.e. add "-type f"?
> >
> > I suppose you should have spoken up when people started adopting that
> > 'find' line all over the place.  Though I honestly doubt we're going to
> > see many packages installing '*.la' non-files.
> >
> Just so we are all clear here: your argument is that more fully correct
> approaches should not be considered in the present and future because
> less fully correct approaches were implemented in the past? And,
> further, that since nothing matching a specific pattern happens to come
> to your mind at he moment, such things do not exist? Perhaps dialing
> back the rhetoric from 11 and considering feedback as an opportunity to
> improve existing code is called for in this case, among others.

I think you might be reading more into this than was intended.

I read his email as lamenting that the horse has left the barn, so to
speak. There are already hundreds of uses of find -name '*.la' -delete
without -type f in the tree, probably in large part because
ltprune.eclass suggests the form without it.

Suggesting dialing down the rhetoric when it appears that you have
overreacted is a bit humorous.

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Sat, 2019-02-23 at 22:19 -0800, Matt Turner wrote:
> On Fri, Feb 22, 2019 at 8:30 PM desultory <desultory@gentoo.org> wrote:
> > 
> > On 02/20/19 02:36, Michał Górny wrote:
> > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > 
> > > > 
> > > > >     # Don't install libtool archives (even for modules)
> > > > > -   prune_libtool_files --all
> > > > > +   find "${D}" -name '*.la' -delete || die
> > > > 
> > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > 
> > > I suppose you should have spoken up when people started adopting that
> > > 'find' line all over the place.  Though I honestly doubt we're going to
> > > see many packages installing '*.la' non-files.
> > > 
> > 
> > Just so we are all clear here: your argument is that more fully correct
> > approaches should not be considered in the present and future because
> > less fully correct approaches were implemented in the past? And,
> > further, that since nothing matching a specific pattern happens to come
> > to your mind at he moment, such things do not exist? Perhaps dialing
> > back the rhetoric from 11 and considering feedback as an opportunity to
> > improve existing code is called for in this case, among others.
> 
> I think you might be reading more into this than was intended.
> 
> I read his email as lamenting that the horse has left the barn, so to
> speak. There are already hundreds of uses of find -name '*.la' -delete
> without -type f in the tree, probably in large part because
> ltprune.eclass suggests the form without it.
> 
> Suggesting dialing down the rhetoric when it appears that you have
> overreacted is a bit humorous.
> 

He simply decided to stalk me and issue ad hominem attacks whenever he
can.  It's how professionals in Gentoo react to critique.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[desultory]

On 02/24/19 04:04, Michał Górny wrote:
> On Sat, 2019-02-23 at 22:19 -0800, Matt Turner wrote:
>> On Fri, Feb 22, 2019 at 8:30 PM desultory <desultory@gentoo.org> wrote:
>>>
>>> On 02/20/19 02:36, Michał Górny wrote:
>>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>>>>
>>>>>
>>>>>>     # Don't install libtool archives (even for modules)
>>>>>> -   prune_libtool_files --all
>>>>>> +   find "${D}" -name '*.la' -delete || die
>>>>>
>>>>> Maybe restrict removal to regular files, i.e. add "-type f"?
>>>>
>>>> I suppose you should have spoken up when people started adopting that
>>>> 'find' line all over the place.  Though I honestly doubt we're going to
>>>> see many packages installing '*.la' non-files.
>>>>
>>>
>>> Just so we are all clear here: your argument is that more fully correct
>>> approaches should not be considered in the present and future because
>>> less fully correct approaches were implemented in the past? And,
>>> further, that since nothing matching a specific pattern happens to come
>>> to your mind at he moment, such things do not exist? Perhaps dialing
>>> back the rhetoric from 11 and considering feedback as an opportunity to
>>> improve existing code is called for in this case, among others.
>>
>> I think you might be reading more into this than was intended.
>>
>> I read his email as lamenting that the horse has left the barn, so to
>> speak. There are already hundreds of uses of find -name '*.la' -delete
>> without -type f in the tree, probably in large part because
>> ltprune.eclass suggests the form without it.
>>
>> Suggesting dialing down the rhetoric when it appears that you have
>> overreacted is a bit humorous.
>>
> 
> He simply decided to stalk me and issue ad hominem attacks whenever he
> can.  It's how professionals in Gentoo react to critique.
> 
I am hardly "stalking" you. I am addressing bad ideas and poor
maintainer behavior, that it happens to be yours is immaterial to me.
Besides, you effectively demanded that I participate more broadly[1], so
do kindly pick one sort of libel and stick to it. As contradicting
yourself not only weakens your argument (were it to have a basis to
begin with), it makes malicious intent more obvious.

As for ad hominem attacks, do kindly present examples, I would be most
interested in any which you can demonstrate are unjustified. When I ask
if/how/why your behavior is acceptable for someone in your roles, I am
seriously asking that question. I want to know the rationale, especially
under what are, at least nominally, the rules governing the interactions
and behaviors which I am inquiring about. Though I will forego linking
to that, as that evidently annoys you.

[1]
https://archives.gentoo.org/gentoo-project/message/b498bcfaf34ffc355eaba3afafd1ee96

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[desultory]

On 02/24/19 01:19, Matt Turner wrote:
> On Fri, Feb 22, 2019 at 8:30 PM desultory <desultory@gentoo.org> wrote:
>>
>> On 02/20/19 02:36, Michał Górny wrote:
>>> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>>>>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>>>>
>>>>
>>>>>     # Don't install libtool archives (even for modules)
>>>>> -   prune_libtool_files --all
>>>>> +   find "${D}" -name '*.la' -delete || die
>>>>
>>>> Maybe restrict removal to regular files, i.e. add "-type f"?
>>>
>>> I suppose you should have spoken up when people started adopting that
>>> 'find' line all over the place.  Though I honestly doubt we're going to
>>> see many packages installing '*.la' non-files.
>>>
>> Just so we are all clear here: your argument is that more fully correct
>> approaches should not be considered in the present and future because
>> less fully correct approaches were implemented in the past? And,
>> further, that since nothing matching a specific pattern happens to come
>> to your mind at he moment, such things do not exist? Perhaps dialing
>> back the rhetoric from 11 and considering feedback as an opportunity to
>> improve existing code is called for in this case, among others.
> 
> I think you might be reading more into this than was intended.
> 
I am reading into it what was written into it.

> I read his email as lamenting that the horse has left the barn, so to
> speak. 
Since we are going with animal husbandry analogies, his specific manner
of rejecting feedback was more akin to leaving the barn door open,
letting the horse go play in traffic and ignoring that there is no real
reason to believe that the horse will not be killed by a vehicle on the
basis of it has only been hit a few times and has not yet succumbed to
its injuries.

> There are already hundreds of uses of find -name '*.la' -delete
> without -type f in the tree, probably in large part because
> ltprune.eclass suggests the form without it.
> 
Which, following the animal husbandry theme brings us to the elephant in
the room [1]:
"
# @MAINTAINER:
# Michał Górny <mgorny@gentoo.org>
"
Given that another developer has noted two different issues with the
suggested boilerplate [2][3], why has he, as a member of QA and as
maintainer of the eclass in question, rejected or simply ignored their
concerns? He would not even need to override another maintainer to fix a
*comment* in that eclass. Is asking for rationale somehow that much of a
problem?

> Suggesting dialing down the rhetoric when it appears that you have
> overreacted is a bit humorous.
> 
Given his behavior, it hardly seems so to me.

> 

[1] https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/ltprune.eclass
[2]
https://archives.gentoo.org/gentoo-dev/message/d528ab54d230afc11430ea9660c7feaa
[3]
https://archives.gentoo.org/gentoo-dev/message/539b9ba7d4b21086bc2ba3b8d11dacdb

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

>>>>> On Wed, 20 Feb 2019, Michał Górny wrote:

> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
>> 
>> 
>> >  	# Don't install libtool archives (even for modules)
>> > -	prune_libtool_files --all
>> > +	find "${D}" -name '*.la' -delete || die
>> 
>> Maybe restrict removal to regular files, i.e. add "-type f"?

> I suppose you should have spoken up when people started adopting that
> 'find' line all over the place.  Though I honestly doubt we're going
> to see many packages installing '*.la' non-files.

I have updated the example in ltprune.eclass now.

That still won't catch regular non-libtool files, but people needing
additional sanity checks can still use the eclass.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Mike Gilbert]

On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Wed, 20 Feb 2019, Michał Górny wrote:
>
> > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> >> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> >>
> >>
> >> >    # Don't install libtool archives (even for modules)
> >> > -  prune_libtool_files --all
> >> > +  find "${D}" -name '*.la' -delete || die
> >>
> >> Maybe restrict removal to regular files, i.e. add "-type f"?
>
> > I suppose you should have spoken up when people started adopting that
> > 'find' line all over the place.  Though I honestly doubt we're going
> > to see many packages installing '*.la' non-files.
>
> I have updated the example in ltprune.eclass now.
>
> That still won't catch regular non-libtool files, but people needing
> additional sanity checks can still use the eclass.

Perhaps we should un-ban the ltprune eclass for EAPI 7?

It seems like it would still be useful to have a way of detecting
libtool-archives instead of removing any file that ends with ".la".

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > >    # Don't install libtool archives (even for modules)
> > > > > -  prune_libtool_files --all
> > > > > +  find "${D}" -name '*.la' -delete || die
> > > > 
> > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > I suppose you should have spoken up when people started adopting that
> > > 'find' line all over the place.  Though I honestly doubt we're going
> > > to see many packages installing '*.la' non-files.
> > 
> > I have updated the example in ltprune.eclass now.
> > 
> > That still won't catch regular non-libtool files, but people needing
> > additional sanity checks can still use the eclass.
> 
> Perhaps we should un-ban the ltprune eclass for EAPI 7?
> 
> It seems like it would still be useful to have a way of detecting
> libtool-archives instead of removing any file that ends with ".la".
> 

How many valid cases for this are there?  For comparison, how many
useless complexity will be added to ebuilds by thoughtless maintainers
using the first thing that seems to work without actually verifying
whether it is necessary?

Because as far as I can see, we're talking about maybe-one-package-
every-decade vs 90%+ ebuilds removing .la files.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Mike Gilbert]

On Sat, Mar 2, 2019 at 5:10 PM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > >    # Don't install libtool archives (even for modules)
> > > > > > -  prune_libtool_files --all
> > > > > > +  find "${D}" -name '*.la' -delete || die
> > > > >
> > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > I suppose you should have spoken up when people started adopting that
> > > > 'find' line all over the place.  Though I honestly doubt we're going
> > > > to see many packages installing '*.la' non-files.
> > >
> > > I have updated the example in ltprune.eclass now.
> > >
> > > That still won't catch regular non-libtool files, but people needing
> > > additional sanity checks can still use the eclass.
> >
> > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> >
> > It seems like it would still be useful to have a way of detecting
> > libtool-archives instead of removing any file that ends with ".la".
> >
>
> How many valid cases for this are there?  For comparison, how many
> useless complexity will be added to ebuilds by thoughtless maintainers
> using the first thing that seems to work without actually verifying
> whether it is necessary?

As a maintainer, any time spent worrying about .la files is wasted
time. We have code that can figure it out automatically and allow me
to stop wasting brain power.

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

On Sat, Mar 2, 2019 at 3:41 PM Mike Gilbert <floppym@gentoo.org> wrote:
>
> On Sat, Mar 2, 2019 at 5:10 PM Michał Górny <mgorny@gentoo.org> wrote:
> >
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > > >    # Don't install libtool archives (even for modules)
> > > > > > > -  prune_libtool_files --all
> > > > > > > +  find "${D}" -name '*.la' -delete || die
> > > > > >
> > > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > > I suppose you should have spoken up when people started adopting that
> > > > > 'find' line all over the place.  Though I honestly doubt we're going
> > > > > to see many packages installing '*.la' non-files.
> > > >
> > > > I have updated the example in ltprune.eclass now.
> > > >
> > > > That still won't catch regular non-libtool files, but people needing
> > > > additional sanity checks can still use the eclass.
> > >
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > >
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > >
> >
> > How many valid cases for this are there?  For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
>
> As a maintainer, any time spent worrying about .la files is wasted
> time. We have code that can figure it out automatically and allow me
> to stop wasting brain power.

Exactly.

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

On Sat, 2019-03-02 at 18:41 -0500, Mike Gilbert wrote:
> On Sat, Mar 2, 2019 at 5:10 PM Michał Górny <mgorny@gentoo.org> wrote:
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller <ulm@gentoo.org> wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > > >    # Don't install libtool archives (even for modules)
> > > > > > > -  prune_libtool_files --all
> > > > > > > +  find "${D}" -name '*.la' -delete || die
> > > > > > 
> > > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > > I suppose you should have spoken up when people started adopting that
> > > > > 'find' line all over the place.  Though I honestly doubt we're going
> > > > > to see many packages installing '*.la' non-files.
> > > > 
> > > > I have updated the example in ltprune.eclass now.
> > > > 
> > > > That still won't catch regular non-libtool files, but people needing
> > > > additional sanity checks can still use the eclass.
> > > 
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > > 
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > > 
> > 
> > How many valid cases for this are there?  For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
> 
> As a maintainer, any time spent worrying about .la files is wasted
> time. We have code that can figure it out automatically and allow me
> to stop wasting brain power.
> 

Do you have any estimates how much more time is wasted on verifying
the result of find one-liner vs. verifying the result of complex
function (which used to have false negatives)?  Please note I'm talking
about effort in case people are doing the right thing, not ignoring
the problems with the function and assuming it will always work fine.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

>>>>> On Sat, 02 Mar 2019, Michał Górny wrote:

> On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
>> Perhaps we should un-ban the ltprune eclass for EAPI 7?
>> 
>> It seems like it would still be useful to have a way of detecting
>> libtool-archives instead of removing any file that ends with ".la".

> How many valid cases for this are there?  For comparison, how many
> useless complexity will be added to ebuilds by thoughtless maintainers
> using the first thing that seems to work without actually verifying
> whether it is necessary?

Removing code that is working perfectly fine (at least, I don't see any
open bug for ltprune.eclass) doesn't look like the right instrument to
inform maintainers about a potential QA issue. After all, the eclass has
a warning in its description that is hard to miss.

OTOH, nobody has spoken up when the patch that deprecated the eclass in
EAPI 7 was posted [1]. So maybe we should wait for a couple of valid use
cases to be raised, before discussing this further.

Ulrich

[1] https://archives.gentoo.org/gentoo-dev/message/a5df51aa115c31737d54ece23446db76

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

On Sun, 2019-03-03 at 20:29 +0100, Ulrich Mueller wrote:
> > > > > > On Sat, 02 Mar 2019, Michał Górny wrote:
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > > 
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > How many valid cases for this are there?  For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
> 
> Removing code that is working perfectly fine (at least, I don't see any
> open bug for ltprune.eclass) doesn't look like the right instrument to
> inform maintainers about a potential QA issue. After all, the eclass has
> a warning in its description that is hard to miss.

Actually, the code sometimes left .la files that weren't really needed
after all.  Then people either replaced it with oneliner, or used '
--all' which made it equivalent with the oneliner.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

[gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Matt Turner]

Nearly all the work is just removing uses of autotools-multilib and
autotools-utils. The new code should work in EAPI 4 and 5. Don't add
support for EAPI 6; that ship has already sailed.
---
There are a number of trivial x11 bumps coming up, so I figured I'd try
to finally add EAPI=7 support to xorg-2.eclass. This is lightly tested,
and I don't feel like an expert at this, so any review and feedback is
appreciated.

I find the if-multilib ... fi blocks a little odd. Is there a better way
to do that?

 eclass/xorg-2.eclass | 80 ++++++++++++++++++++++++++------------------
 1 file changed, 48 insertions(+), 32 deletions(-)

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 74660e7f213..eb2aa1594b4 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: xorg-2.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Author: Tomáš Chvátal <scarabeus@gentoo.org>
 # Author: Donnie Berkholz <dberkholz@gentoo.org>
-# @SUPPORTED_EAPIS: 4 5
+# @SUPPORTED_EAPIS: 4 5 7
 # @BLURB: Reduces code duplication in the modularized X11 ebuilds.
 # @DESCRIPTION:
 # This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -44,16 +44,16 @@ fi
 : ${XORG_MULTILIB:="no"}
 
 # we need to inherit autotools first to get the deps
-inherit autotools autotools-utils eutils libtool multilib toolchain-funcs \
+inherit autotools eutils libtool multilib toolchain-funcs \
 	flag-o-matic ${FONT_ECLASS} ${GIT_ECLASS}
 
 if [[ ${XORG_MULTILIB} == yes ]]; then
-	inherit autotools-multilib
+	inherit multilib-minimal
 fi
 
-EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
+EXPORTED_FUNCTIONS="src_prepare src_configure src_unpack src_compile src_install pkg_postinst pkg_postrm"
 case "${EAPI:-0}" in
-	4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare src_configure" ;;
+	4|5|7) ;;
 	*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
@@ -129,7 +129,16 @@ for arch in ${XORG_EAUTORECONF_ARCHES}; do
 	EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
 done
 DEPEND+=" ${EAUTORECONF_DEPENDS}"
-[[ ${XORG_EAUTORECONF} != no ]] && DEPEND+=" ${EAUTORECONF_DEPEND}"
+if [[ ${XORG_EAUTORECONF} != no ]] ; then
+	case "${EAPI:-0}" in
+		4|5)
+			DEPEND+=" ${EAUTORECONF_DEPEND}"
+			;;
+		7)
+			BDEPEND+=" ${EAUTORECONF_DEPEND}"
+			;;
+	esac
+fi
 unset EAUTORECONF_DEPENDS
 unset EAUTORECONF_DEPEND
 
@@ -311,20 +320,6 @@ xorg-2_src_unpack() {
 	[[ -n ${FONT_OPTIONS} ]] && einfo "Detected font directory: ${FONT_DIR}"
 }
 
-# @FUNCTION: xorg-2_patch_source
-# @DESCRIPTION:
-# Apply all patches
-xorg-2_patch_source() {
-	debug-print-function ${FUNCNAME} "$@"
-
-	# Use standardized names and locations with bulk patching
-	# Patch directory is ${WORKDIR}/patch
-	# See epatch() in eutils.eclass for more documentation
-	EPATCH_SUFFIX=${EPATCH_SUFFIX:=patch}
-
-	[[ -d "${EPATCH_SOURCE}" ]] && epatch
-}
-
 # @FUNCTION: xorg-2_reconf_source
 # @DESCRIPTION:
 # Run eautoreconf if necessary, and run elibtoolize.
@@ -335,14 +330,17 @@ xorg-2_reconf_source() {
 		*-aix* | *-winnt*)
 			# some hosts need full eautoreconf
 			[[ -e "./configure.ac" || -e "./configure.in" ]] \
-				&& AUTOTOOLS_AUTORECONF=1
+				&& XORG_EAUTORECONF=yes
 			;;
 		*)
 			# elibtoolize required for BSD
 			[[ ${XORG_EAUTORECONF} != no && ( -e "./configure.ac" || -e "./configure.in" ) ]] \
-				&& AUTOTOOLS_AUTORECONF=1
+				&& XORG_EAUTORECONF=yes
 			;;
 	esac
+
+	[[ ${XORG_EAUTORECONF} != no ]] && eautoreconf
+	elibtoolize --patch-only
 }
 
 # @FUNCTION: xorg-2_src_prepare
@@ -351,9 +349,10 @@ xorg-2_reconf_source() {
 xorg-2_src_prepare() {
 	debug-print-function ${FUNCNAME} "$@"
 
-	xorg-2_patch_source
+	default
 	xorg-2_reconf_source
-	autotools-utils_src_prepare "$@"
+
+	[[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
 }
 
 # @FUNCTION: xorg-2_font_configure
@@ -447,17 +446,28 @@ xorg-2_src_configure() {
 		local selective_werror="--disable-selective-werror"
 	fi
 
-	local myeconfargs=(
+	local econfargs=(
 		${dep_track}
 		${selective_werror}
 		${FONT_OPTIONS}
 		"${xorgconfadd[@]}"
 	)
 
+	# Handle static-libs found in IUSE, disable them by default
+	if in_iuse static-libs; then
+		econfargs+=(
+			--enable-shared
+			$(use_enable static-libs static)
+		)
+	fi
+
 	if [[ ${XORG_MULTILIB} == yes ]]; then
-		autotools-multilib_src_configure "$@"
+		multilib_src_configure() {
+			ECONF_SOURCE="${S}" econf "${econfargs[@]}"
+		}
+		multilib-minimal_src_configure "$@"
 	else
-		autotools-utils_src_configure "$@"
+		econf "${econfargs[@]}" "$@"
 	fi
 }
 
@@ -468,9 +478,12 @@ xorg-2_src_compile() {
 	debug-print-function ${FUNCNAME} "$@"
 
 	if [[ ${XORG_MULTILIB} == yes ]]; then
-		autotools-multilib_src_compile "$@"
+		multilib_src_compile() {
+			emake "$@" || die 'emake failed'
+		}
+		multilib-minimal_src_compile "$@"
 	else
-		autotools-utils_src_compile "$@"
+		emake "$@" || die 'emake failed'
 	fi
 }
 
@@ -484,9 +497,12 @@ xorg-2_src_install() {
 	local install_args=( docdir="${EPREFIX}/usr/share/doc/${PF}" )
 
 	if [[ ${XORG_MULTILIB} == yes ]]; then
-		autotools-multilib_src_install "${install_args[@]}"
+		multilib_src_install() {
+			emake DESTDIR="${D}" "${install_args[@]}" "$@" install || die "emake install failed"
+		}
+		multilib-minimal_src_install "$@"
 	else
-		autotools-utils_src_install "${install_args[@]}"
+		emake DESTDIR="${D}" "${install_args[@]}" "$@" install || die "emake install failed"
 	fi
 
 	if [[ -n ${GIT_ECLASS} ]]; then
-- 
2.19.2

Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 317 bytes --]

>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:

> Nearly all the work is just removing uses of autotools-multilib and
> autotools-utils. The new code should work in EAPI 4 and 5. Don't add
> support for EAPI 6; that ship has already sailed.

AFAICS, adding EAPI 6 support wouldn't require any additional code?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Matt Turner]

On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>
> > Nearly all the work is just removing uses of autotools-multilib and
> > autotools-utils. The new code should work in EAPI 4 and 5. Don't add
> > support for EAPI 6; that ship has already sailed.
>
> AFAICS, adding EAPI 6 support wouldn't require any additional code?

I think that is true. (I have no strong preference on whether to add
EAPI 6 support. I just figured that anything that gets an EAPI bump
now should go to the latest available)

Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Tue, 19 Feb 2019 22:46:23 -0800 Matt Turner wrote:
> On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller <ulm@gentoo.org> wrote:
> >
> > >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >
> > > Nearly all the work is just removing uses of autotools-multilib and
> > > autotools-utils. The new code should work in EAPI 4 and 5. Don't add
> > > support for EAPI 6; that ship has already sailed.
> >
> > AFAICS, adding EAPI 6 support wouldn't require any additional code?
> 
> I think that is true. (I have no strong preference on whether to add
> EAPI 6 support. I just figured that anything that gets an EAPI bump
> now should go to the latest available)

This is not always possible. E.g. I have a package with optional
java support. Since java is still EAPI 6 I can't use EAPI 7.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Matt Turner]

On Sun, Feb 24, 2019 at 4:44 AM Matija Skala <mskala@gmx.com> wrote:
>
> Dne sreda, 20. februar 2019 ob 05:45:41 CET je Matt Turner napisal:
> > +     default
> >       xorg-2_reconf_source
> > -     autotools-utils_src_prepare "$@"
> > +
> > +     [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> >  }
> >
>
> On EAPI=7, this code would apply ${PATCHES} twice.

Thank you! Removed.