Date: Sat, 10 Mar 2007 00:57:10 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Ade Lovett <ade@FreeBSD.org> Cc: freebsd ports <freebsd-ports@freebsd.org> Subject: Re: Ports 104877 causing big problems Message-ID: <45F272E6.9070501@FreeBSD.org> In-Reply-To: <45808CB8-07C8-4680-A11D-8982BD8A6B52@FreeBSD.org> References: <45F1DDE2.5030404@FreeBSD.org> <BE66AB56-E0B4-420A-910D-9C10DB9AF24D@FreeBSD.org> <45F1EA6A.6070904@FreeBSD.org> <FB399CF7-11E2-4CC9-8C91-7D6850B7B2D8@FreeBSD.org> <20070310023034.c5939c48.jylefort@FreeBSD.org> <7CF1749C-3254-46AC-ABDD-BAB0D84ED7A1@FreeBSD.org> <45F2546F.60401@FreeBSD.org> <45808CB8-07C8-4680-A11D-8982BD8A6B52@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ade Lovett wrote:
>
> On Mar 09, 2007, at 22:47 , Doug Barton wrote:
>> On it's face I find the idea of bumping PORTREVISION for every port
>> that uses libtool in any form a sort of silly proposition. The change
>> in behavior was introduced in Mk/*, I think it's reasonable to expect
>> that the fix happen there too.
>
> Ok. Let's take this opportunity right here to take a step back and look
> at the rather larger picture.
[ Description of how we got to this point snipped ]
> End result, FreeBSD is now considerably more "in-line" with Linux and
> pkgsrc with respect to autotools handling. It's by no means perfect,
> but it's *a lot* better than it was.
No one is debating that, at least I am certainly not. You've done a
lot of hard work, and I agree that we're better off now than we were
before. In fact, I was one of the people that supported the decision
to install the .la files, so I'm right here with you.
> So, seemingly innocuous changes like changing the semantics of what a
> well-established port variable like GNU_CONFIGURE has potentially
> far-reaching consequences.
No argument there either.
> The armchair generals are more than welcome
> to debate to their hearts content the idyllic solution, but there are
> real-world constraints that prevent such nirvana.
I don't know what the right solution is, so I'm not going to argue
strongly in favor of changing the behavior of GNU_CONFIGURE. However
my gut instinct is that what you're proposing is simply not feasible,
and furthermore I don't think we can wait that long. This problem gets
worse almost every time one of our users updates or installs a port.
> As autotools maintainer, I have laid out a potential course of action to
> this (as yet unproven) problem
If you don't think the example of mine that you snipped proves that
there is a problem, perhaps you can describe in what way you find it
deficient, and what sort of testing you would consider valid?
> it's not related to +REQUIRED_BY, as
> already pointed out. Braino on my part, this is compile and run-time
> issues, not a ports dependency issue. My apologies.
I think it's both, since there is absolutely no reason that mtr,
xscreensaver, or 3/4 of the other ports that I currently have in
/var/db/pkg/libgpg-error/+REQUIRED_BY should have registered a
dependency on that library, since they don't need or use it.
> I don't for one minute pretend to be the absolute authority on
> autotools, however I believe that I happen to know a reasonable amount,
> resulting from my shepherding of them over the past few years. Of
> course, if someone else wants to step up to the plate and continue the
> good fight, that's fine by me. Send me your freefall login, and the
> ports and infrastructure will be handed over in a heartbeat.
I think you're getting extremely reactionary and defensive here, and
there is no reason for either. No one is attacking you, or your work.
What we are saying is that there _is_ a problem. The exact cause(s)
and solution(s) of the problem may not be known at this time, but it
would be a big help if you could recognize that there is in fact a
problem, and start working with us on a reasonable solution.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F272E6.9070501>