From owner-svn-ports-head@freebsd.org Fri Jun 9 02:53:06 2017 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1396DD895B6; Fri, 9 Jun 2017 02:53:06 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBA9C7AEBD; Fri, 9 Jun 2017 02:53:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 0433A45ED; Fri, 9 Jun 2017 02:53:05 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id B44E55368; Fri, 9 Jun 2017 02:53:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id R6n4TTfQSGGv; Fri, 9 Jun 2017 02:52:59 +0000 (UTC) Subject: Re: svn commit: r442588 - in head/www: nginx nginx-full DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 393805363 To: Alexey Dokuchaev , Adam Weinberger Cc: "Sergey A. Osokin" , Bartek Rutkowski , Adam Weinberger , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org References: <201706042038.v54KcQMf001482@repo.freebsd.org> <20170605001807.GA55217@FreeBSD.org> <20170606093911.GA98412@FreeBSD.org> From: Bryan Drewery Organization: FreeBSD Message-ID: <0130a05b-8f04-1008-16bf-d7f047823cae@FreeBSD.org> Date: Thu, 8 Jun 2017 22:52:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170606093911.GA98412@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gAQC5hpUQPlbDn4trngmRDqJgpP7f80pN" X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 02:53:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gAQC5hpUQPlbDn4trngmRDqJgpP7f80pN Content-Type: multipart/mixed; boundary="BjCvGCLdVwMxHGlLcnrtFCmdTiUnfGp3h"; protected-headers="v1" From: Bryan Drewery To: Alexey Dokuchaev , Adam Weinberger Cc: "Sergey A. Osokin" , Bartek Rutkowski , Adam Weinberger , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Message-ID: <0130a05b-8f04-1008-16bf-d7f047823cae@FreeBSD.org> Subject: Re: svn commit: r442588 - in head/www: nginx nginx-full References: <201706042038.v54KcQMf001482@repo.freebsd.org> <20170605001807.GA55217@FreeBSD.org> <20170606093911.GA98412@FreeBSD.org> In-Reply-To: <20170606093911.GA98412@FreeBSD.org> --BjCvGCLdVwMxHGlLcnrtFCmdTiUnfGp3h Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/6/17 5:39 AM, Alexey Dokuchaev wrote: > On Mon, Jun 05, 2017 at 05:50:06PM -0600, Adam Weinberger wrote: >>> On 4 Jun, 2017, at 18:18, Sergey A. Osokin wrote: >>> >>> Hi Bartek and Adam, >>> >>> I don't think I can get this, so two questions for you guys: >>> o) what was the reason to bump PORTREVISION in www/nginx? >>> o) wouldn't it btter to just bump PORTREVISION in www/nginx-full? >> >> Hi Sergey, >=20 > [ Wrapping very long lines ] >=20 >> I'll give Bartek a chance to explain in more detail, but I supported a= n >> nginx bump because it was less complex for the future. >> >> If nginx-full got a bump, then it would need to be bumped every time >> nginx got bumped, or nginx would have to be bumped by two and nginx-fu= ll's >> PORTREVISION line gets removed, and then the line has to be removed at= the >> next nginx update or reset. At the end of the day, bumping nginx was m= ore >> straightforward. It triggers an update for everyone else, but becomes = less >> invasive over the long haul. >=20 > It seems that everyone bumps port revisions whenever they please these = days; > wondering about it just a waste of time. Just an exampler: r442562, wh= ere > it was bumped for pkg-descr change (sic!) in a port that takes consider= able > time to build. :-( >=20 pkg-descr is part of the generated package. Bumping PORTREVISION in that commit had a real impact and change. Plus the actual content change is not a small spelling change. > # svn diff -c r442561 ^/ > Index: head/emulators/wine/pkg-descr > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- head/emulators/wine/pkg-descr (revision 442560) > +++ head/emulators/wine/pkg-descr (revision 442561) > @@ -5,8 +5,12 @@ without the performance or memory usage penalties > a similar look and feel to other applications on your desktop. >=20 > Many applications already work, more or less, including versions of > -Microsoft Office and several games. > +Microsoft Office and many games. >=20 > +Use this port for 32-bit Windows binaries in an i386 environment or > +64-bit Windows binaries in an amd64 environment; use emulators/i386-wi= ne > +for 32-bit Windows binaries in an amd64 environment. > + It's explaining something to users about the proper use of the port and how to obtain the right package for the right environment. Yes it hurts to rebuild a port for something like this, but it is absolutely correct. Building ports synchronously in your terminal while waiting for them is the root problem here; building ports asynchronously in the background with a package builder and not caring when they are done is the right solution. It would be nice if the tools and metadata were smart enough to just reuse the existing package and update the pkg-descr within it. Until that time a rebuild is needed. > WWW: http://www.winehq.org/ >=20 > Gerald Pfeifer --=20 Regards, Bryan Drewery --BjCvGCLdVwMxHGlLcnrtFCmdTiUnfGp3h-- --gAQC5hpUQPlbDn4trngmRDqJgpP7f80pN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZOg2HAAoJEDXXcbtuRpfPOvMH/1nKbarE/kHAyDkJ1GJoM/J6 QzsZDTItIvsIlPcrDe+HWGaeRQE/s6PMYIF1qsmgdQGcmPpCq0Kw5FaSwXxyOhaX 63+45iC5vWrz9dM8XWRi4lBuMV+n+zI3gHpK2fUjCFiA1ZF3yVPVU1MxlTz1D8Kv oGCMJ1zOlS5jbQj8eCcI45vZQprecft50BumXt4LX9/JZGLB9Hx6f7GAFSKYfAVy gHcmgMzLmX7ud0+IO9hkpiXaHqjV8S0IVdjmAosWtV6I0R5spayy15uzE6Voe47Z RwU4K/KaErvV+QBxZlx2pijz9z5R8d1zyO3VZl/8Xh3+hQGFgRpaZVRYRRHsunI= =Euh1 -----END PGP SIGNATURE----- --gAQC5hpUQPlbDn4trngmRDqJgpP7f80pN--