public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Date: Mon, 28 Jun 2010 11:09:12 +0000 (UTC)	[thread overview]
Message-ID: <pan.2010.06.28.11.09.12@cox.net> (raw)
In-Reply-To: 20100628091632.14dca3c9@snowcone

Ciaran McCreesh posted on Mon, 28 Jun 2010 09:16:32 +0100 as excerpted:

> --as-needed does not prevent breakage. It shoves some breakages under
> the carpet so they're sometimes less visible, and sometimes easier to
> fix when they happen. However, it does absolutely nothing to address any
> of the root causes of the breakage, and it does introduce new breakages
> itself.
> 
> Had one tenth of the effort that had been put into running around and
> adding in hacks to work around a deliberately broken toolchain instead
> been put into fixing libtool and delivering better slotting mechanisms,
> none of this would be an issue.
> 
> Or is the policy "we've started running towards the cliff and we've
> already debated the merits of jumping off it, so all you're allowed to
> discuss now is how we remove the fence"?

OK, let's take that last analogy of yours, and expand it to better match 
rather more of the situation.

The current situation is that we have a big mountain (with known unsafe 
cliffs) in the way of a journey we happen to make somewhat regularly.

Now there's a 10 kilometer (or read mile, if you prefer) road over the 
mountain, with the next shortest alternative being a 110 km road around 
the mountain.  Unfortunately, because the road over the mountain currently 
transits a particular cliff without tested guardrails, it's gated off 
(your fence) and marked with large warning signs, unguarded cliff ahead, 
proceed at your own risk.  The 110 km road around the mountain is thus 
what most folks take now, with only a few deciding they can manage the 
risk if they go carefully (often after someone else points out the 
shortcut, and describes the problems so they can be careful at that 
cliff), and choosing to take that road.

That's the current situation.  Everyone seems to agree that we have the 
mountain, the 110 km long route around it that most folks take, and a 
potentially quite dangerous 10 km shortcut over it, that some few take 
instead.

OK, as it so happens, a proposed guard rail along the dangerous parts has 
been surveyed, contracted, and is pretty much finished.  Pretty much all 
that remains now is painting the stripes on the new section, and putting 
up the various curve left, curve right, etc, signage, and getting official 
sign-offs on the guard rails at an already listed set of particular 
sections of the cliff that need it.

Except...

There's a particular set of individuals that despite that almost finished 
section of road, only awaiting the paint, signage, and official signoffs, 
continues to argue that's not the /proper/ solution, that the /proper/ 
solution is to tunnel straight thru a particular section of the mountain, 
thereby bypassing the cliff entirely.  In fact, not only do they claim 
that the tunnel is the proper solution and would in fact be less dangerous 
than transiting the cliff even with the guard rails is, they claim that 
the tunnel would have actually cost less to construct than the section of 
road transiting the cliff did.

So here we are, playing politics at the meeting set to give the final go-
ahead to complete the final inspections, the painting and the signage on 
the road transiting the cliff, a road that's all finished and actually in 
use by some already, save for that, and we still have this "tunnel bloc" 
of folks opposing it, continuing to argue that the tunnel is the /proper/ 
solution.

Who knows at this point?  The tunnel may in fact have been cheaper, and 
there's no question that it would have prevented the occasional careless 
driver still crashing thru the guard rails and going over the cliff.  But 
the point is, we don't have that tunnel, but we do have the already 
basically finished road, well surveyed and already constructed, with only 
a bit of painting and certification left, yet the "tunnel bloc" is still 
opposing the road, arguing that the gate and warnings be maintained as 
they are, until that tunnel is properly finished, even at the cost of all 
those travelers having to take the 110 km long way around until that 
tunnel is completed and opened at some unpredictable time in the future, 
possibly a decade or more away.

So yes, we ARE arguing that the final preparations be made and that the 
gate currently barring the way to that cliff come down.  The fact of the 
matter is that yes, there is a cliff, but there's also a well constructed 
road with proper guard rails transiting that cliff, and pending the paint, 
signage, and final signoffs, it's ready to open and there's no reason  
other than the political opposition of the "tunnel bloc" not to make those 
last preparations, and then remove that gate and the warnings currently 
barring the way.

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




  reply	other threads:[~2010-06-28 11:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-28  1:09 [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults Nirbheek Chauhan
2010-06-28  7:23 ` [gentoo-dev] " Christian Faulhammer
2010-06-28  7:35 ` [gentoo-dev] " Ciaran McCreesh
2010-06-28  7:44   ` Samuli Suominen
2010-06-28  7:51     ` Ciaran McCreesh
2010-06-28  8:04       ` [gentoo-dev] " Nikos Chantziaras
2010-06-28  8:08       ` [gentoo-dev] " Samuli Suominen
2010-06-28  8:10         ` Nirbheek Chauhan
2010-06-28 13:43           ` Thomas Anderson
2010-06-28 13:59             ` Roy Bamford
2010-06-28 14:05               ` Ciaran McCreesh
2010-06-29  3:30                 ` Jeroen Roovers
2010-06-29  7:23                   ` Ciaran McCreesh
2010-06-29  8:46                     ` Alex Alexander
2010-06-29 17:25                       ` David Leverton
2010-06-29 17:59                         ` Alex Alexander
2010-07-05 13:01                 ` [gentoo-dev] " Peter Hjalmarsson
2010-07-05 13:47                   ` Arun Raghavan
2010-07-05 14:25                   ` David Leverton
2010-06-28  8:16         ` [gentoo-dev] " Ciaran McCreesh
2010-06-28 11:09           ` Duncan [this message]
2010-06-28 11:46             ` [gentoo-dev] " David Leverton
2010-06-28 15:21               ` Brian Harring
2010-06-29  6:27                 ` [gentoo-dev] [OT] h v l Mike Frysinger
2010-06-29  6:35                   ` Luis Araujo
2010-06-28  8:17 ` [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults Markos Chandras
2010-06-28  9:21   ` Nirbheek Chauhan
2010-06-28  8:42 ` Pacho Ramos
2010-06-28 12:11 ` Alex Alexander
2010-06-29 17:04 ` David Leverton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2010.06.28.11.09.12@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox