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

[Mike Frysinger]

On Thursday 16 May 2013 15:28:39 Warren Young wrote:
> 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."

how about you focus on the things i've actually said rather than making up 
things and attributing them to me.  i've chopped a couple of sections of your 
e-mail as they were largely redundant.

> 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.

so you're proposing we never make a change because we haven't located and 
tested every single project ever conceived w/autotools ?  obviously that is 
literally impossible and any such proposal is the exact antithesis to 
progress.

in order to make a change, you need to weigh real world impact which means you 
need samples.  the samples stated by the various distros (arguably the largest 
builders of source code) are significantly strong data points to indicate that 
this is a dead feature.

> I *still* run across autoconfiscated packages using "configure.in",
> despite years of warnings from Autoconf.

autoconf has never warned about it afaik.  automake-1.12 was the first release 
to complain, and that was released 24 Apr 2012 (just barely a year).  which 
means in order to see these warnings, people need to be running a recent 
distro (checking ubuntu real quick shows it still doesn't have it), as well as 
be using automake (some projects like to use just autoconf).  which means 
there are a good number of developers who aren't seeing the warning even 
today.

so i don't know what you're referring to here.

> When autoconf stops recognizing configure.in,
> I fully expect to hear wails, "Why did you break this?"

so what ?  they'll rename things and move on.

> 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.

a mere implementation detail

> And no, this thread doesn't count as fair warning.

i don't think anyone has considered "announced on mailing list" fair warning 
for autotool packages.  that is what NEWS is for as well as generated warnings 
when you run them.

> [1] When I characterize Gentoo as anti-commercial, I simply mean that
> the distro proper does not contain paid commercial software, to my
> knowledge.

we have plenty of ebuilds in the main tree that install proprietary binary-
only packages.  as in, you need to buy/license the package before you even get 
a chance to install it.  i'm also aware of companies who use Gentoo to 
build/maintain their internal proprietary packages which either never get 
released externally, or only done so as binary packages.  so i guess your 
characterization is inaccurate.

> 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.

i've worked on closed sourced projects (both internal-only and released to the 
world) at various companies in the past, as well as supported other companies 
writing closed source software.  there's no generalization you can make to 
cover them all, although "stupidity" is frequently a common theme.
-mike

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