Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Warren Young]

On 5/15/2013 14:27, Mike Frysinger wrote:
> On Wednesday 15 May 2013 15:25:31 Warren Young wrote:
> we've got pretty good coverage for anything passably relevant (and then some).

So, because Gentoo has N text editors in the repo, the N+1th text editor 
must port to Gentoo without problems?

You're committing a logical fallacy here, hasty generalization.  "All 
things in class A have property B, hence all things have property B."

The packages in Gentoo are ipso facto packages that *can* port to 
Gentoo.  You can't infer from that that all packages port to Gentoo 
without requiring adjustment.

> > I wouldn't be surprised if there were an iceberg effect here: it could
> > well be that ~90% of all source trees using the autotools aren't even
> > publicly visible, much less incorporated into the major Linux distros.
>
> then they're irrelevant to this sub thread.

Why?

You propose changing the way autoconf works based on a sampling of 
projects using it.  A large sampling to be sure, but probably not 
anywhere near a majority of those using autotools.

You *think* you know how your change will affect all those projects you 
don't get to see, but you do not actually know, because you're working 
from a biased sample.  (Biased because it's an inherently anti-closed 
source, anti-commercial[1] sample.)

This seems like it might be a relevant consideration to me.

> when things break w/Gentoo, our devs/users tend to file bugs.

Fallen tree fallacy.

When the entry in the bug tracker (in a forest of bug trackers) is not 
filled out, does the bug exist?

> if Gentoo blowing away your rinky dinky config.sub hack breaks your project,
> then take it as a sign that You're Doing It Wrong :).

Quite possibly.  Truly, I agree.

But now go ask Stefano Lattarini how well-intentioned changes, made to 
the behavior of the autotools without a gradual phase-in period over 
years affect real world user reaction to those changes.

I *still* run across autoconfiscated packages using "configure.in", 
despite years of warnings from Autoconf.  I've even sent off bug reports 
to those packages about it, and the obsolete name remains in their 
source repo to this day.  When autoconf stops recognizing configure.in, 
I fully expect to hear wails, "Why did you break this?"

This idea isn't entirely bad.  It's attempting to fix a real problem. 
There's another problem pressing up against it from the other direction, 
though: an implicit promise built up over decades of the Autotools' 
existence that certain behaviors are allowed.  When the rules change 
without warning, people get upset.

And no, this thread doesn't count as fair warning.  The vast majority of 
autotools users don't read this list, and likely couldn't find this 
thread in Google if they had a problem that this thread explained.  What 
those users see is that their OS of choice upgrades the autotools, and 
"suddenly" the rules have changed.

-----
[1] When I characterize Gentoo as anti-commercial, I simply mean that 
the distro proper does not contain paid commercial software, to my 
knowledge.  The closed, secretive mindset behind such software must 
result in some differences in software development practice from that 
used by open source, so you cannot extend your knowledge from open 
source software to predict how closed source software development works.