Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jul 2012 02:15:28 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        Baptiste Daroussin <bapt@FreeBSD.org>
Cc:        freebsd-ports@FreeBSD.org
Subject:   Disappointed in how you've handled the pkg-config issue
Message-ID:  <50110AB0.8020906@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
Baptiste,

I'm fairly upset about how you've handled this. This is going to be a
long message, so I'll try to put the important parts first.

1. When we talked about this problem on IRC you said that you were going
on vacation for 10 days starting real soon, and wouldn't be addressing
this issue till you returned. As a result I started working on the
problem of the bogus run dep on pkg-config, and have continued to work
on finding the dependencies that need a build dep. Now all of that work
is wasted. (Sucks to be me .... moving on.)

2. If you're still going on vacation, it means you made a major
infrastructure change right before leaving.

3. While I think it's great that you're dealing with the pkg-config
bootstrap issue, that's completely orthogonal to the issue of the bogus
run dep, and AFAICT isn't something that is actually holding anything
back atm.

4. You posted a plan 2 days ago, without only a minimal patch, and
AFAICT you haven't received any feedback on it. If I had known that you
planned to go ahead immediately I would have made responding to your
plan a much higher priority, because there are numerous problems with it.

5. Your actual execution of the change was seriously flawed. Let's start
with the fact that every file in your pkgconf port had its contents
duplicated. Your UPDATING patch had the wrong instructions for
portmaster and portupgrade, some of your other changes also had
duplicate content, and there was at least one typo (ImageMagick) that
I've found so far. And your first commit was apparently incomplete, as
you didn't change all of the instances of USE_GNOME=pkgconfig. And those
are just the problems we know about in the first 2 hours. If you had
posted a complete patch and waited for proper review, most, if not all
of these problems would have been found and fixed ahead of time.

6. I don't know if the fact that your initial change wasn't functional
means that you didn't do an exp-run, or if it means that you didn't
commit what you tested. Either of these mistakes is a pretty serious
issue all on its own.

7. You reverted all of my work without discussion, or even notice. Even
if you want to claim portmgr authority on this one, it's still not
acceptable to just stroll in and make these kinds of changes without at
least notifying your fellow committer first. If I had done this exact
thing to you, you'd be furious. Think about it.

As for my problems with your suggested approach ...

1. There is absolutely no need for a macro here. In the overwhelming
majority of cases the proper solution (once dependent ports are fixed)
is a simple build dep. Although it's theoretically possible that a port
such as an IDE may (bogusly) utilize a run dep to make sure the tool is
available post-install, no port has yet been identified that actually
*needs* a run dep on pkg-config.

Not only is the macro not necessary, it's harmful in at least 2 ways:
	a. Every line in bsd.port.mk causes everything that calls it to run a
little bit slower. All by itself that should be enough reason not to do
this.
	b. Hiding things that should be simple behind macros is the exact line
of reasoning that caused the bogus run dep bug to appear in the first
place. Most of bsd.gnome.mk is not necessary, and shouldn't exist
anyways. This run dep bug went unnoticed for so long precisely because
it was hidden behind a macro.

2. You say "some ports" need the CONFIGURE_ENV. How many? Is it a
majority? In that case the macro starts to make more sense, but you
didn't give us the information. If it's only a few then it should be
added to those ports, not every port.

3. Your patch to bsd.port.mk is needlessly complicated. Wouldn't this
work instead?

.if ${USE_PKGCONFIG:L} == yes || ${USE_PKGCONFIG:L} == build

4. The name of the macro makes no sense. The name of the new tool is
pkgconf, why isn't the macro USE_PKGCONF ?

But that's just the implementation. My biggest problem is the mindset
that is inherent in your approach. By doing $something to address the
bogus run dep problem, you've effectively de-motivated anyone else from
actually working to solve the real problem. Sure, some people will
convert their ports to properly restrict it to a build-only dep, but
most never will. These kinds of sweeping changes never get done unless
motivated individuals/groups actually step in to do them. By doing
$something before fixing the actual problem you've just pushed the real
problem down the road.

Meanwhile, I was (fairly successfully) working on a way to actually
solve the problem of identifying what ports needed build deps on
pkg-config when I realized that a simpler way to do that would be to
just grep the pointyhat build logs and identify the ports that were
using pkg-config that way. If we had done that, we could have fixed the
build dep problem *first*, with no fear of breakage. This includes the
things like KDE libs which use pkg-config opportunistically, and we
probably would have brought in a few more that do this that we hadn't
previously identified. But as I said, I didn't give either of those
projects a high priority since you told me you were going on vacation.

Finally, and I really hope that I'm wrong about this, I can't help but
think that you rushed into this change (right before a vacation?)
because the bogus run dep problem is something that I volunteered to
help fix. You told me that you were going to do an exp-run with the line
from bsd.gnome.mk commented out on Monday, and I was eagerly
anticipating the results since it would be easy to see and fix the
big-picture breakage; which was going to make the rest of my planned
approach much easier to deal with. Instead, you seem determined to own
this problem, and rushed in with an incomplete, initially broken, and
arguably pathological change that only addresses a small part of the
problem, and doesn't actually fix the bogus run dep issue.

This whole situation is very disappointing.

Doug

-- 

    Change is hard.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50110AB0.8020906>