From owner-freebsd-ports@FreeBSD.ORG Thu Jul 26 10:56:37 2012 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70586106566C; Thu, 26 Jul 2012 10:56:37 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5341C8FC08; Thu, 26 Jul 2012 10:56:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6QAuaFv015074; Thu, 26 Jul 2012 10:56:36 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6QAua2k015073; Thu, 26 Jul 2012 10:56:36 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Thu, 26 Jul 2012 10:56:34 +0000 From: Baptiste Daroussin To: Doug Barton Message-ID: <20120726105633.GM13771@ithaqua.etoilebsd.net> References: <50110AB0.8020906@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AQYPrgrEUc/1pSX1" Content-Disposition: inline In-Reply-To: <50110AB0.8020906@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-ports@FreeBSD.org Subject: Re: Disappointed in how you've handled the pkg-config issue X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 10:56:37 -0000 --AQYPrgrEUc/1pSX1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2012 at 02:15:28AM -0700, Doug Barton wrote: > Baptiste, >=20 > 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.= =2E. >=20 > 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 por= ts tree for example: your fusefs-libs update broke lots of the ports depending= on it etc. >=20 > 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. >=20 > 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. >=20 > 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 >=20 > 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=3Dpkgconfig. 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. >=20 > 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 be= en tested on pointyhat (except that I forgot that svn revert would not have re= moved 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 ! >=20 > 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. >=20 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 ... >=20 > 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 variabl= e 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 spe= ak about and having a macro may help to easier converting the ports to use the= one =66rom base if it ever happens >=20 > 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. >=20 > 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. >=20 > 3. Your patch to bsd.port.mk is needlessly complicated. Wouldn't this > work instead? >=20 > .if ${USE_PKGCONFIG:L} =3D=3D yes || ${USE_PKGCONFIG:L} =3D=3D build Yes it should also do the trick, feel free to send a patch to improve the Mk/bsd.*.mk it is always appreciated >=20 > 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 >=20 > 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. >=20 It is funny because it is exactly the other way around feedback that I rece= ived since that commit. regards, Bapt --AQYPrgrEUc/1pSX1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlARImEACgkQ8kTtMUmk6Ey12ACeL537rnlTdapstDz+wa4Bqwad N7cAnAzsK5ei0zSe2Hnb9W1eV0c9UYHf =Xq1H -----END PGP SIGNATURE----- --AQYPrgrEUc/1pSX1--