Date: Thu, 26 Jul 2012 10:56:34 +0000 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: freebsd-ports@FreeBSD.org Subject: Re: Disappointed in how you've handled the pkg-config issue Message-ID: <20120726105633.GM13771@ithaqua.etoilebsd.net> In-Reply-To: <50110AB0.8020906@FreeBSD.org> References: <50110AB0.8020906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120726105633.GM13771>