[gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Michał Górny]

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

Hi,

As you haven't expected at all, the PMS is a specific spec which
doesn't document much of common sense. Therefore, the way econf is
currently declared leaves the freedom of adding its arguments anywhere
in the ./configure invocation [1].

By that, I mean that:

    econf --libdir=/lib

could actually result in:

    ./configure --libdir=/lib ... --libdir=<here-goes-default-libdir>

The only option guaranteed to be handled properly is --prefix which is
directly processed by econf.

Why I'm bringing this up? Because of bug #406117. Long story short,
it's mostly about Ciaran having the imagination to let paludis pass
./configure arguments in semi-random order. As a result, default
--disable-dependency-tracking goes after explicit
--enable-dependency-tracking from the ebuild.

Now, what are your thoughts? Shall we fix PMS to explicitly state
the argument order or implement ugly hacks in ebuilds?

[1]:http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-13500011.3.3.7
[2]:https://bugs.gentoo.org/show_bug.cgi?id=406117

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Markos Chandras]

On 29 April 2013 06:55, Michał Górny <mgorny@gentoo.org> wrote:
> Hi,
>
> As you haven't expected at all, the PMS is a specific spec which
> doesn't document much of common sense. Therefore, the way econf is
> currently declared leaves the freedom of adding its arguments anywhere
> in the ./configure invocation [1].
>
> By that, I mean that:
>
>     econf --libdir=/lib
>
> could actually result in:
>
>     ./configure --libdir=/lib ... --libdir=<here-goes-default-libdir>
>
> The only option guaranteed to be handled properly is --prefix which is
> directly processed by econf.
>
> Why I'm bringing this up? Because of bug #406117. Long story short,
> it's mostly about Ciaran having the imagination to let paludis pass
> ./configure arguments in semi-random order. As a result, default
> --disable-dependency-tracking goes after explicit
> --enable-dependency-tracking from the ebuild.
>
> Now, what are your thoughts? Shall we fix PMS to explicitly state
> the argument order or implement ugly hacks in ebuilds?
>
> [1]:http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-13500011.3.3.7
> [2]:https://bugs.gentoo.org/show_bug.cgi?id=406117
>
> --
> Best regards,
> Michał Górny

Fair enough. The common sense is for econf to pass the "fixed"
arguments right after ./configure and then any user specific options
would go at the end. But since PMS is not clear about it, you can't
blame people for not doing it properly.

so +1 to fix PMS.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 407 bytes --]

On Monday 29 April 2013 01:55:49 Michał Górny wrote:
> Now, what are your thoughts? Shall we fix PMS to explicitly state
> the argument order or implement ugly hacks in ebuilds?

portage has always inserted implicit args before the args given by the ebuild 
to econf.  PMS omitting the ordering information is simply an oversight to be 
clarified, not functionality that may be relied upon.
-mike

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Mon, 29 Apr 2013 14:36:41 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 29 April 2013 01:55:49 Michał Górny wrote:
> > Now, what are your thoughts? Shall we fix PMS to explicitly state
> > the argument order or implement ugly hacks in ebuilds?
> 
> portage has always inserted implicit args before the args given by
> the ebuild to econf.  PMS omitting the ordering information is simply
> an oversight to be clarified, not functionality that may be relied
> upon.

As you can see in the bug, we're not discussing anything related to EAPI
0 behaviour, so this argument is irrelevant. We're discussing a change
in a later EAPI, where the change had nothing to say about ordering.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Michał Górny]

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

On Mon, 29 Apr 2013 19:49:17 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Mon, 29 Apr 2013 14:36:41 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
> > On Monday 29 April 2013 01:55:49 Michał Górny wrote:
> > > Now, what are your thoughts? Shall we fix PMS to explicitly state
> > > the argument order or implement ugly hacks in ebuilds?
> > 
> > portage has always inserted implicit args before the args given by
> > the ebuild to econf.  PMS omitting the ordering information is simply
> > an oversight to be clarified, not functionality that may be relied
> > upon.
> 
> As you can see in the bug, we're not discussing anything related to EAPI
> 0 behaviour, so this argument is irrelevant. We're discussing a change
> in a later EAPI, where the change had nothing to say about ordering.

There's a difference between 'we' and 'you alone'.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Mon, 29 Apr 2013 21:09:36 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > As you can see in the bug, we're not discussing anything related to
> > EAPI 0 behaviour, so this argument is irrelevant. We're discussing
> > a change in a later EAPI, where the change had nothing to say about
> > ordering.
> 
> There's a difference between 'we' and 'you alone'.

Well yes, you're trying to ignore the actual issue and go around
retroactively breaking things rather than just change the wording in
EAPI 6. But that doesn't change the fact that the actual bug in the
ebuild wouldn't be showing up if it were EAPI 0.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 896 bytes --]

On Monday 29 April 2013 15:17:40 Ciaran McCreesh wrote:
> On Mon, 29 Apr 2013 21:09:36 +0200 Michał Górny wrote:
> > > As you can see in the bug, we're not discussing anything related to
> > > EAPI 0 behaviour, so this argument is irrelevant. We're discussing
> > > a change in a later EAPI, where the change had nothing to say about
> > > ordering.
> > 
> > There's a difference between 'we' and 'you alone'.
> 
> Well yes, you're trying to ignore the actual issue and go around
> retroactively breaking things rather than just change the wording in
> EAPI 6. But that doesn't change the fact that the actual bug in the
> ebuild wouldn't be showing up if it were EAPI 0.

claiming breakage is a red herring.  i'll wager that clarifying PMS to match 
realistic intentions and the largest PM won't break a single package.  
appending args over the econf args is asinine.
-mike

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Rich Freeman]

On Mon, Apr 29, 2013 at 3:28 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>
> claiming breakage is a red herring.  i'll wager that clarifying PMS to match
> realistic intentions and the largest PM won't break a single package.
> appending args over the econf args is asinine.

If many packages actually break with the change I'm sure everybody
will see the sense in making the change in a new EAPI.  However, from
the sound of things all these packages would already be broken with
portage, and I'm sure those would have been flagged by the
tinderbox/users/etc by now if that were the case.

Having econf options override build system options "just makes sense."
 If that wasn't documented, well, let's document it.  However, this
isn't some DoD project with a 35k page requirement specification -
there are going to be elements of PMS behavior that simply aren't
defined.  Lack of specification causing inconsistent solutions is
understandable, but if there is a "common sense" solution we really
should embrace it.

Rich

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ulrich Mueller]

>>>>> On Mon, 29 Apr 2013, Ciaran McCreesh wrote:

> On Mon, 29 Apr 2013 14:36:41 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>> portage has always inserted implicit args before the args given by
>> the ebuild to econf. PMS omitting the ordering information is
>> simply an oversight to be clarified, not functionality that may be
>> relied upon.

+1

> As you can see in the bug, we're not discussing anything related to
> EAPI 0 behaviour, so this argument is irrelevant. We're discussing a
> change in a later EAPI, where the change had nothing to say about
> ordering.

In the discussions that led to inclusion of the feature in EAPI 4, it
was implicit that it would be possible to override the default. This
can only work if "$@" goes after all default options.

You had even claimed yourself that overriding the default with
econf --enable-dependency-tracking would always be possible:
http://archives.gentoo.org/gentoo-dev/msg_0189c554085ac8352b5a2e05647a1d97.xml

Ulrich

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Mon, 29 Apr 2013 22:53:30 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> > As you can see in the bug, we're not discussing anything related to
> > EAPI 0 behaviour, so this argument is irrelevant. We're discussing a
> > change in a later EAPI, where the change had nothing to say about
> > ordering.
> 
> In the discussions that led to inclusion of the feature in EAPI 4, it
> was implicit that it would be possible to override the default. This
> can only work if "$@" goes after all default options.

But that wasn't got approved by the Council...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ulrich Mueller]

>>>>> On Mon, 29 Apr 2013, Ciaran McCreesh wrote:

>> In the discussions that led to inclusion of the feature in EAPI 4, it
>> was implicit that it would be possible to override the default. This
>> can only work if "$@" goes after all default options.

> But that wasn't got approved by the Council...

Sure it was. Read the full thread that belongs to the message quoted
earlier: You had announced the EAPI 3 (what later became 4) branch
with the --d-d-t feature, asking council members for comments. Your
message mentioning econf --enable-dependency-tracking was a reply to
leio's question about the feature.

How else should one understand this, if not as a clarification that
overriding the default should be possible?

Ulrich

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Tue, 30 Apr 2013 00:22:23 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Mon, 29 Apr 2013, Ciaran McCreesh wrote:
> >> In the discussions that led to inclusion of the feature in EAPI 4,
> >> it was implicit that it would be possible to override the default.
> >> This can only work if "$@" goes after all default options.
> 
> > But that wasn't got approved by the Council...
> 
> Sure it was. Read the full thread that belongs to the message quoted
> earlier: You had announced the EAPI 3 (what later became 4) branch
> with the --d-d-t feature, asking council members for comments. Your
> message mentioning econf --enable-dependency-tracking was a reply to
> leio's question about the feature.
> 
> How else should one understand this, if not as a clarification that
> overriding the default should be possible?

What ultimately got approved by the Council, and what implementers
should be following, is the wording which ended up in PMS.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Rich Freeman]

On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> What ultimately got approved by the Council, and what implementers
> should be following, is the wording which ended up in PMS.
>

I can't speak for everywhere, but even in the highly regulated
environment I work in, an error in a specification is a good reason to
fix the specification, not to change the implementation.

Whether this is retroactive or forward-going should be based on the
practical impact of each, not on whether the council approved
something without appreciating every possible ramification of the
wording as-written.  Specs are a communication tool - not writ from
heaven.

Arguing over whether we should go ahead and break a whole bunch of
packages in the interim just to comply with the spec until it is fixed
is basically reducing human intelligence to algorithmic behavior.
There is a reason that we program the machines, and not the other way
around (yet).

If it really is better for our users to follow the spec as-is for now,
I'm sure everybody is all ears, but I haven't seen any examples
offered.  The council is of course welcome to chime in if they'd
rather the portage maintainers do so.

This whole thing seems best chalked up to well-intending people making
omissions (maybe), and the virtue of competent developers who don't
just blindly follow the spec when it doesn't make sense.

Sure, fix the spec, but it makes more sense to make this retroactive
unless somebody can really point to something that this breaks.  If
the damage from doing so exceeded the damage from not doing so you
probably wouldn't even need the council to get everybody to go along
with you.

Rich

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[vivo75]

On 04/30/13 01:12, Rich Freeman wrote:
> On Mon, Apr 29, 2013 at 6:27 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> What ultimately got approved by the Council, and what implementers
>> should be following, is the wording which ended up in PMS.
>>
> I can't speak for everywhere, but even in the highly regulated
> environment I work in, an error in a specification is a good reason to
> fix the specification, not to change the implementation.
Just out of curiosity what happen in a highly regulated environment if
an individual systematically try to find loopholes and use them against
the environment? In production?
Or to say it another way to boycott things staying in the rules, lawyers
enjoy this, but programmers?
</troll>
>
> Whether this is retroactive or forward-going should be based on the
> practical impact of each, not on whether the council approved
> something without appreciating every possible ramification of the
> wording as-written.  Specs are a communication tool - not writ from
> heaven.
>
> Arguing over whether we should go ahead and break a whole bunch of
> packages in the interim just to comply with the spec until it is fixed
> is basically reducing human intelligence to algorithmic behavior.
> There is a reason that we program the machines, and not the other way
> around (yet).
>
> If it really is better for our users to follow the spec as-is for now,
> I'm sure everybody is all ears, but I haven't seen any examples
> offered.  The council is of course welcome to chime in if they'd
> rather the portage maintainers do so.
>
> This whole thing seems best chalked up to well-intending people making
> omissions (maybe), and the virtue of competent developers who don't
> just blindly follow the spec when it doesn't make sense.
>
> Sure, fix the spec, but it makes more sense to make this retroactive
> unless somebody can really point to something that this breaks.  If
> the damage from doing so exceeded the damage from not doing so you
> probably wouldn't even need the council to get everybody to go along
> with you.
>
> Rich
>

[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Duncan]

Rich Freeman posted on Mon, 29 Apr 2013 19:12:37 -0400 as excerpted:

> This whole thing seems best chalked up to well-intending people making
> omissions (maybe), and the virtue of competent developers who don't just
> blindly follow the spec when it doesn't make sense.

Actually, much as it's widely agreed there's value in porting an app to 
at least one other arch even if there's not enough potential users there 
to justify it directly, because it helps to root out and get bugs fixed 
that would never be found otherwise, I'd say the same applies here:

There's value in someone being just contrarian enough to purposefully 
look for the strangest or most illogical read of a spec and (initially) 
implement it that way, in ordered to root out and get the bugs in the 
spec fixed.  That said...

> Sure, fix the spec, but it makes more sense to make this retroactive
> unless somebody can really point to something that this breaks.

Agreed.  Once the bug has been demonstrated and a fix to the spec is in 
process, the value of a contrarian read of the existing spec has been 
exploited and there's no longer any value in it.  Just fix it (both the 
spec and the contrarian implementations), as soon as possible (and 
possibly retroactively for the spec), which given the nature of 
specifications and the bureaucracy which surrounds them, will by 
definition tend to be sooner for the implementation than for the spec, a 
fix for which will take its time to work thru the bureaucracy.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Tue, 30 Apr 2013 05:30:03 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> There's value in someone being just contrarian enough to purposefully 
> look for the strangest or most illogical read of a spec and
> (initially) implement it that way, in ordered to root out and get the
> bugs in the spec fixed.  That said...

I highly doubt the person implementing the code for Paludis was doing
it in a contrarian way. As far as I can see, he simply implemented what
the spec says.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[vivo75]

On 04/30/13 13:12, Ciaran McCreesh wrote:
> On Tue, 30 Apr 2013 05:30:03 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> There's value in someone being just contrarian enough to purposefully 
>> look for the strangest or most illogical read of a spec and
>> (initially) implement it that way, in ordered to root out and get the
>> bugs in the spec fixed.  That said...
> I highly doubt the person implementing the code for Paludis was doing
> it in a contrarian way. As far as I can see, he simply implemented what
> the spec says.
>
Nice to know. For how the discussion has gone before the opposite seemed
true.
Now, is it possible to alter the behaviour of paludis to act, still
following the specs, in a way compatible with portage and which seem
more logical to the majority of people writing this thread?
Or at least discuss the possibility for paludis to change behaviour?
It seem there would be some gain and nearly no loss, and make everyone
happy (or at least try to)

Best regards,
Francesco

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Tue, 30 Apr 2013 13:42:22 +0200
"vivo75@gmail.com" <vivo75@gmail.com> wrote:
> Now, is it possible to alter the behaviour of paludis to act, still
> following the specs, in a way compatible with portage and which seem
> more logical to the majority of people writing this thread?

Sure, and as an added bonus, we can do that selectively from EAPI 6
onwards, avoiding the need to introduce a breaking change to the spec.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Rich Freeman]

On Tue, Apr 30, 2013 at 7:46 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 30 Apr 2013 13:42:22 +0200
> "vivo75@gmail.com" <vivo75@gmail.com> wrote:
>> Now, is it possible to alter the behaviour of paludis to act, still
>> following the specs, in a way compatible with portage and which seem
>> more logical to the majority of people writing this thread?
>
> Sure, and as an added bonus, we can do that selectively from EAPI 6
> onwards, avoiding the need to introduce a breaking change to the spec.

There is little value in going back and forth on this.  Portage
already implements the desired logic, and I suspect that is unlikely
to change.  Anybody who uses paludis can always use portage when they
run into something that doesn't compile the way they want it to, and
as far as I can tell Portage implements PMS just fine anyway (the spec
does not explicitly specify that build system options must override
econf options, and I doubt that the Council would accept a retroactive
change to codify the broken behavior in EAPI 5).

The only people who really suffer are those who wish to use Paludis,
and they're welcome to fork it, wait until the whole tree migrates to
EAPI 6, use portage on occasion, or offer up their suffering to the
souls in Exherbo.  ;)

Rich

[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Duncan]

Ciaran McCreesh posted on Tue, 30 Apr 2013 12:12:13 +0100 as excerpted:

> On Tue, 30 Apr 2013 05:30:03 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> There's value in someone being just contrarian enough to purposefully
>> look for the strangest or most illogical read of a spec and (initially)
>> implement it that way, in ordered to root out and get the bugs in the
>> spec fixed.  That said...
> 
> I highly doubt the person implementing the code for Paludis was doing it
> in a contrarian way. As far as I can see, he simply implemented what the
> spec says.

Not saying it has to be deliberate.  There's some people who seem to just 
seem to have the gift.  The way they think just naturally finds the bugs 
in the spec, the loophole in the law, whatever.  They're terribly 
frustrating to people who equally naturally seem to find the most 
tolerant read of things, but if it was deliberate at some point years 
ago, it's no longer so; it just comes naturally.

And what I'm saying is that as terribly frustrating as it can be, there's 
some value in that, because they /do/ end up finding the bugs/loopholes/
whatever, which is good as then they can be fixed.  And there's some 
value in recognizing that good for what it is.

Another analogy would be that these people are human versions of the 
kernel's trinity fuzz tester...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Rich Freeman]

On Tue, Apr 30, 2013 at 8:30 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Another analogy would be that these people are human versions of the
> kernel's trinity fuzz tester...

Requirements generally are not intended to be defensible to fuzz
testing, or completely determinate.  Rather, they're intended to be
detailed in the things that are really critical, and less detailed
where everybody should be able to get the gist of what is specified.

When you actually take the time to write an absolutely unambiguous
requirement spec a few things happen:
1.  Nobody bothers to read it.
2.  Those who read it can't grok it, because the forest is invisible
for the trees.
3.  The result of 1+2 is that the spec usually ends up being wrong.

So, if the goal of the exercise is to be able to blame the people who
signed the requirement for anything that goes wrong, then an extremely
detailed requirements document is generally the best way to go.  If
the goal is to just get everybody on the same page and align subject
matter experts with those who will be designing/coding the software,
then the appropriate level of details is generally lower.

There are also compromises like a series of nested documents that
spell out the specs in increasing levels of detail (use cases,
business requirements, functional requirements, design specifications,
etc).  This a fairly bureaucratic exercise, and rarely do orgs have
the time to properly document and maintain trace-ability between
these, so the result is that it ends up being a lot of paper done for
the sake of checking boxes and the code is even more likely to be
broken because everybody is looking at different documents that are
never completely in-sync.  However, done right (ie, with cost overruns
like that of the F-35) this can allow projects to scale to fairly
large sizes.

Most of us are here because we find it "fun," so I think the simplest
solution is to just do the right thing and treat requirements docs as
useful tools when they're actually useful.  I think PMS has been a
great thing for Gentoo, but we shouldn't treat changing it like
changing the TCP spec.

Rich

[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Duncan]

Rich Freeman posted on Tue, 30 Apr 2013 08:40:50 -0400 as excerpted:

> I think PMS has been a great thing for Gentoo, but we shouldn't treat
> changing it like changing the TCP spec.

Thanks.  +=

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ulrich Mueller]

Below is a patch that brings the spec in line with common sense.

Ulrich


From 34023bdee8fb9b60e6a91e1f340bef5c97f07e05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= <ulm@gentoo.org>
Date: Tue, 30 Apr 2013 14:59:15 +0200
Subject: [PATCH] econf arguments override default options.

This matches long-time Portage behaviour, and for later added options
like --disable-dependency-tracking it follows the clarification given here:
http://archives.gentoo.org/gentoo-dev/msg_0189c554085ac8352b5a2e05647a1d97.xml
See also bug 406117.
---
 pkg-mgr-commands.tex | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pkg-mgr-commands.tex b/pkg-mgr-commands.tex
index aa0c873..ed15ad8 100644
--- a/pkg-mgr-commands.tex
+++ b/pkg-mgr-commands.tex
@@ -136,8 +136,8 @@ has returned.
 \begin{description}
 \item[econf] Calls the program's \t{./configure} script. This is designed to work with GNU
     Autoconf-generated scripts. Any additional parameters passed to \t{econf} are passed directly
-    to \t{./configure}. \t{econf} will look in the current working directory for a configure script
+    to \t{./configure} and override any of the default options below.
+    \t{econf} will look in the current working directory for a configure script
     unless the \t{ECONF\_SOURCE} environment variable is set, in which case it is taken to be the
     directory containing it. \t{econf} must pass the following options to the configure script:
 
-- 
1.8.1.5

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ulrich Mueller]

>>>>> On Tue, 30 Apr 2013, Ulrich Mueller wrote:

> Below is a patch that brings the spec in line with common sense.

And in fact, I wonder why we're even discussing the issue.
Paludis was fixed already more than a year ago:
http://git.exherbo.org/paludis/paludis.git/commit/?id=ad2ae2ba3b6fc8f113638a86de0e7d8a6a046091

Ulrich

Re: [gentoo-pms] Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Tue, 30 Apr 2013 15:13:25 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
>  \item[econf] Calls the program's \t{./configure} script. This is
> designed to work with GNU Autoconf-generated scripts. Any additional
> parameters passed to \t{econf} are passed directly
> -    to \t{./configure}. \t{econf} will look in the current working
> directory for a configure script
> +    to \t{./configure} and override any of the default options below.

"Override" is a dodgy word, since we don't know how ./configure does.
Specify how the arguments are passed, which we have control over, not
how they behave.

And it still needs Council approval...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Tue, 30 Apr 2013 15:25:08 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Tue, 30 Apr 2013, Ulrich Mueller wrote:
> 
> > Below is a patch that brings the spec in line with common sense.
> 
> And in fact, I wonder why we're even discussing the issue.
> Paludis was fixed already more than a year ago:
> http://git.exherbo.org/paludis/paludis.git/commit/?id=ad2ae2ba3b6fc8f113638a86de0e7d8a6a046091

We're discussing a matter of principle...

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ryan Hill]

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

On Tue, 30 Apr 2013 12:12:13 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 30 Apr 2013 05:30:03 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> > There's value in someone being just contrarian enough to purposefully 
> > look for the strangest or most illogical read of a spec and
> > (initially) implement it that way, in ordered to root out and get the
> > bugs in the spec fixed.  That said...
> 
> I highly doubt the person implementing the code for Paludis was doing
> it in a contrarian way. As far as I can see, he simply implemented what
> the spec says.

Then the person implementing the code for Paludis is either a monkey or a
robot*. Anyone capable of reasoning could puzzle out the implications of not
allowing user-given options to override the defaults.  Obviously you can write
code that follows a spec but is still broken or useless.


*or both (?!)

-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Tue, 30 Apr 2013 19:52:03 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> Then the person implementing the code for Paludis is either a monkey
> or a robot*.
> 
> *or both (?!)

I believe they prefer the term "mathematician".

-- 
Ciaran McCreesh


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

[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ulrich Mueller]

>>>>> On Tue, 30 Apr 2013, Ryan Hill wrote:
> Then the person implementing the code for Paludis is either a monkey
> or a robot*. Anyone capable of reasoning could puzzle out the
> implications of not allowing user-given options to override the
> defaults. Obviously you can write code that follows a spec but is
> still broken or useless.

> *or both (?!)

Oh please... The person simply made a mistake, which happens when
programming, and which he fixed. No reason for calling him names.

Ulrich

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[David Leverton]

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

On 1 May 2013 02:52, Ryan Hill <dirtyepic@gentoo.org> wrote:

> Then the person implementing the code for Paludis is either a monkey or a
> robot*.
>
> *or both (?!)
>

Alternative possibilities include ninja, zombie and wizard.

[-- Attachment #2: Type: text/html, Size: 561 bytes --]

[gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ryan Hill]

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

On Wed, 1 May 2013 08:57:35 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Tue, 30 Apr 2013, Ryan Hill wrote:
> > Then the person implementing the code for Paludis is either a monkey
> > or a robot*. Anyone capable of reasoning could puzzle out the
> > implications of not allowing user-given options to override the
> > defaults. Obviously you can write code that follows a spec but is
> > still broken or useless.
> 
> > *or both (?!)
> 
> Oh please... The person simply made a mistake, which happens when
> programming, and which he fixed. No reason for calling him names.

Sorry, I was under the impression that they were refusing to acknowledge it as a
mistake on the grounds that it was allowed by the spec, despite the
consequences, and demanding ebuilds to be "fixed" instead.  I have other names
for those people I could use but I doubt you'd like them any better.


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-dev] [RFC] Shall econf append its arguments to end of ./configure invocation?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 629 bytes --]

On Tuesday 30 April 2013 12:38:03 Ciaran McCreesh wrote:
> On Tue, 30 Apr 2013 15:25:08 +0200 Ulrich Mueller wrote:
> > >>>>> On Tue, 30 Apr 2013, Ulrich Mueller wrote:
> > > Below is a patch that brings the spec in line with common sense.
> > 
> > And in fact, I wonder why we're even discussing the issue.
> > Paludis was fixed already more than a year ago:
> > http://git.exherbo.org/paludis/paludis.git/commit/?id=ad2ae2ba3b6fc8f1136
> > 38a86de0e7d8a6a046091
> 
> We're discussing a matter of principle...

we all get the principle.  the only contribution you've made here is to waste 
everyone's time.
-mike

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

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Ciaran McCreesh]

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

On Wed, 1 May 2013 19:40:06 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Wed, 1 May 2013 08:57:35 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > >>>>> On Tue, 30 Apr 2013, Ryan Hill wrote:
> > > Then the person implementing the code for Paludis is either a
> > > monkey or a robot*. Anyone capable of reasoning could puzzle out
> > > the implications of not allowing user-given options to override
> > > the defaults. Obviously you can write code that follows a spec
> > > but is still broken or useless.
> > 
> > > *or both (?!)
> > 
> > Oh please... The person simply made a mistake, which happens when
> > programming, and which he fixed. No reason for calling him names.
> 
> Sorry, I was under the impression that they were refusing to
> acknowledge it as a mistake on the grounds that it was allowed by the
> spec, despite the consequences, and demanding ebuilds to be "fixed"
> instead.  I have other names for those people I could use but I doubt

Er, we are. Following the spec is not a mistake. If there's a mistake,
it was made by the Council when they approved the wording.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[Rich Freeman]

On Thu, May 2, 2013 at 9:55 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Er, we are. Following the spec is not a mistake. If there's a mistake,
> it was made by the Council when they approved the wording.

Both Portage and Paludis are following the spec.  The spec isn't
incorrect, it just doesn't fully describe the necessary behavior.  At
worst it is incomplete.  Virtually all specs are.

The only way you'll ever have a complete spec is if you call your
implementation the spec, and then you lose the benefit of having specs
in the first place.

However, it is a moot point - a proposed improvement has already been
made, and the matter of adopting it is before the council.

Rich