On Thu, Jul 26, 2012 at 02:15:28AM -0700, Doug Barton wrote: > 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.
And I'm fairly upset by your constant insultant and irrespectful behaviour...
>
> 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.)
No I had to hurry working on this because you have started breaking the ports
tree for example: your fusefs-libs update broke lots of the ports depending on
it etc.
>
> 2. If you're still going on vacation, it means you made a major
> infrastructure change right before leaving.
I'm going on vacation next week, I have time to fix any problems occuring.
>
> 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.
I did received feedback and positives one. Maybe people the people giving
feedback where affraid of some endless bikesched, who knows why they could think
that it can happen
>
> 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.
Yes I did a mistake and I can explain it.
I first use psvn to commit which added propoerties to every single Makefile
touched, to I reverted everything locally a reapplied the patch that has been
tested on pointyhat (except that I forgot that svn revert would not have removed
any new files, so reapplying the patch duplicated the content of that file).
I was about to commit the fix when you did it (thanks again for having done it).
So yes I made a small mistake easily fixable What a big deal !
>
> 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.
>
I didn't reverted your work at all, I just converted it to the new knob has
everybody does in that case.
> 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.
There is a need for a macro because it currently set the PKG_CONFIG variable and
in the futur it will do more like automatically defining the PKG_CONFIG_PATH
variable etc.
Plus having something like pkgconf in base is something a lot of people speak
about and having a macro may help to easier converting the ports to use the one
from base if it ever happens
>
> 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.
Where are you patches to the famework to improve the situation, you spend a lot
of time complaining again and again, but we don't see much really coming.
>
> 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.
This is depending on autotools because and how the upstream are using it
every single upstream using correctly autotools check for the PKG_CONFIG env
variable.
>
> 3. Your patch to bsd.port.mk is needlessly complicated. Wouldn't this
> work instead?
>
> .if ${USE_PKGCONFIG:L} == yes || ${USE_PKGCONFIG:L} == build
Yes it should also do the trick, feel free to send a patch to improve the
Mk/bsd.*.mk it is always appreciated
>
> 4. The name of the macro makes no sense. The name of the new tool is
> pkgconf, why isn't the macro USE_PKGCONF ?
Because the macro is there to help ports dealing with pkgconfig files which are
installed in libdata/pkgconfig
>
> 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.
>
It is funny because it is exactly the other way around feedback that I received
since that commit.
regards,
Bapt
pgpIWJkI3nMui.pgp
Description: PGP signature
