From owner-svn-ports-head@FreeBSD.ORG Fri Aug 22 05:05:34 2014 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A6AD2D5; Fri, 22 Aug 2014 05:05:34 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 165BE33F9; Fri, 22 Aug 2014 05:05:32 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s7M558vJ066640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Aug 2014 14:05:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s7M554vD033038; Fri, 22 Aug 2014 14:05:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 22 Aug 2014 14:01:57 +0900 (JST) Message-Id: <20140822.140157.2098353200954412611.hrs@allbsd.org> To: marino@freebsd.org, freebsd.contact@marino.st Subject: Re: svn commit: r365590 - in head/cad/spice: . files From: Hiroki Sato In-Reply-To: <53F6724A.6000602@marino.st> References: <20140822.070939.1253386656808735449.hrs@allbsd.org> <53F66EE5.7080500@FreeBSD.org> <53F6724A.6000602@marino.st> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Aug_22_14_01_57_2014_546)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 22 Aug 2014 14:05:26 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, bdrewery@FreeBSD.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Aug 2014 05:05:34 -0000 ----Security_Multipart(Fri_Aug_22_14_01_57_2014_546)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Marino wrote in <53F6724A.6000602@marino.st>: fr> fr> On 8/22/2014 00:12, Bryan Drewery wrote: fr> > On 8/21/2014 5:09 PM, Hiroki Sato wrote: fr> >> John Marino wrote fr> >> in <53F663B2.3000800@marino.st>: fr> >> fr> >> fr> On 8/21/2014 21:41, Hiroki Sato wrote: fr> >> fr> > Author: hrs fr> >> fr> > Date: Thu Aug 21 19:41:06 2014 fr> >> fr> > New Revision: 365590 fr> >> fr> > URL: http://svnweb.freebsd.org/changeset/ports/365590 fr> >> fr> > QAT: https://qat.redports.org/buildarchive/r365590/ fr> >> fr> >> ... fr> >> fr> >> fr> I'm sorry, but using freebsd-specific in a ports vendor fr> >> fr> makefile is NOT an improvement and frankly puts the build at risk on fr> >> fr> DragonFly. fr> >> fr> fr> >> fr> I wish there was a rule that ports should not use system make fragments. fr> >> fr> This is not a good practice. This port had a perfectly working and fr> >> fr> generic makefile before. fr> >> fr> fr> >> fr> There's a good chance this just broke spice on DragonFly as the system fr> >> fr> make file these are different. fr> >> fr> >> I can understand that vendor's Makefile should be platform-neutral, fr> >> but I do not think there is advantage to maintain fr> >> ${FILESDIR}/Makefile in a way not to use FreeBSD-specific stuff fr> >> because it is used only by the port. Should we care about build on fr> >> DragonFly? fr> > fr> > No! This is FreeBSD. Ports is only officially supported on FreeBSD. fr> > fr> > There are plenty of other ports using bsd.prog.mk. fr> fr> Putting the first statement aside which frankly contradicts other fr> statements made by other portmgr and completely belittles my fr> contributions, this is a bad idea for FreeBSD too. You are not fr> containing the port to ports collection. If the system makefile fr> fragment changes, it affects the port. It's a dumb decision. If you fr> want these makefile fragments, put a tailored copy of Mk/ fr> fr> In this PARTICULAR case, I staged the port. I fixed that makefile. HRS fr> changes serve no purpose other than to potentially break my work. fr> Obviously that is not his intention, but that is the result. fr> fr> Frankly he should revert this immediately. It was working before fr> everywhere. I take the maintainership because I have plans to add further changes to this port. Like the other change I committed just now, they will be ones primarily for supporting new devices. Probably I will change files/Makefile further. I changed files/Makefile not to use bsd.prog.mk as I understand that your criticism was based on the use of it. However, still I do not understand what exactly you are pointing out by words "break my work". I used bsd.prog.mk just because it was handy, so if my change was inappropriate I will consider fixing. You first mentioned the breakage was on DragonFly but you did not give specifics. If someone will be happy by changing something, please provide enough information. My opinion about using bsd.prog.mk is as follows. DragonFly's bsd.*.mk should be based on FreeBSD's and I believe my change has been compatible for over 10 years. When a vendor-supplied Makefile is not reliable, I usually avoid to create a hand-rolling install target including lines of "install foo ${PREFIX}/bin" since maintenance is hard for me. Although there are some in ports I am maintaining that have such an install target, they suffer from changes to the ports tree. When staging support was added they became broken and needed to add ${DESTDIR} or ${STAGEDIR} manually, and -j# support for such kind of install targets is sensitive to () as tijl@ explains. Macros in bsd.prog.mk (and bsd.files.mk) are safe at least with regard to them. I do not insist that bsd.prog.mk is free from compatibility issue even in FreeBSD you mentioned. However, I personally believe risk of using it is smaller than (or as small as) one of hand-rolled target because I eventually needed to fix Makefiles before as explained above. Thus, I do not either recommend or deny using bsd.prog.mk, while I use it in ports I maintain. I just think the risk is small and I can fix it if there is a problem because I am the maintainer. -- Hiroki ----Security_Multipart(Fri_Aug_22_14_01_57_2014_546)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlP2zsUACgkQTyzT2CeTzy0JqACfY34iuecl9ouo/SVfsprouN6S FZ0AoKQGAGQHi6N1jiXJqMScYtDR4kDj =mvW5 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Aug_22_14_01_57_2014_546)----