From owner-freebsd-ports@FreeBSD.ORG Wed Sep 3 18:58:19 2014 Return-Path: Delivered-To: ports@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 326BF498 for ; Wed, 3 Sep 2014 18:58:19 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1027B13CC for ; Wed, 3 Sep 2014 18:58:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s83IwIIU037560 for ; Wed, 3 Sep 2014 18:58:18 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s83IwIVO037559 for ports@freebsd.org; Wed, 3 Sep 2014 18:58:18 GMT (envelope-from bdrewery) Received: (qmail 90145 invoked from network); 3 Sep 2014 13:58:16 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 3 Sep 2014 13:58:16 -0500 Message-ID: <5407649A.80500@FreeBSD.org> Date: Wed, 03 Sep 2014 13:57:30 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Baptiste Daroussin , Tijl Coosemans Subject: Re: [BRAINSTORMING] simplifying maintainer's life References: <20140903082538.GE63085@ivaldir.etoilebsd.net> <20140903145614.158f8e89@kalimero.tijl.coosemans.org> <20140903135029.GK63085@ivaldir.etoilebsd.net> <20140903165622.3bff54e0@kalimero.tijl.coosemans.org> <20140903150018.GL63085@ivaldir.etoilebsd.net> In-Reply-To: <20140903150018.GL63085@ivaldir.etoilebsd.net> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RBbOvr7EB5b2OgOFL5v2G5Vd1tqieaU6L" Cc: ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 18:58:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RBbOvr7EB5b2OgOFL5v2G5Vd1tqieaU6L Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/3/2014 10:00 AM, Baptiste Daroussin wrote: > On Wed, Sep 03, 2014 at 04:56:22PM +0200, Tijl Coosemans wrote: >> On Wed, 3 Sep 2014 15:50:30 +0200 Baptiste Daroussin wrote: >>> On Wed, Sep 03, 2014 at 02:56:14PM +0200, Tijl Coosemans wrote: >>>> On Wed, 3 Sep 2014 10:25:39 +0200 Baptiste Daroussin wrote: >>>>> On of the most borring thing IMHO in the plist maintainance is all = the >>>>> directories. >>>> >>>> Another idea is to support shell glob patterns (*?[) in pkg-plist. = This >>>> is possible now thanks to staging. It would allow moving PORTDOCS, >>>> PORTDATA and PORTEXAMPLES to pkg-plist. But more importantly, it wo= uld >>>> allow automatic plists that some ports create in post-install to be >>>> turned back into a real pkg-plist. Without glob patterns some pkg-p= lists >>>> are just too long or too complicated depending on options. >>> >>> We could also say pack everything that is in that stage directory. >>> >>> The problem is right now I do like static plist because if something >>> fails to build for $reason, that the plist doesn't find a file in the= >>> staging area and we notice quite quickly that something as failed. >>> with autoplist or globbing we do lose this feature and we need to way= >>> deal with it. >>> In anycase we won't make full autoplist because we still need to be >>> able to specify credentials files per files if needed. But glob is >>> really appealing :) >> >> I completely agree :) Files should be listed explicitly if possible, >> but sometimes it's very inconvenient and in these cases some ports >> roll their own autoplist implementations which worse than having a >> static pkg-plist with a few glob patterns. >> >> Moving PORTDOCS etc. to pkg-plist means all package content is listed >> in one file. That will probably simplify check-plist too. >=20 > Right I'll implement globbing (one level not recursive) >=20 > regards, > Bapt >=20 I disagree globbing simplifies check-plist. I see it making it much more complicated. I support autoplist. The point that if something failed to build and is now missing for packaging, yet expected, exists today already. I never have carefully analyzed the build of a port to see if it is building everything I expected down to every file. I trust that if there is an error building something I requested that it will halt the build. Does this make me a bad maintainer? Probably. I'm sure most maintainers do this. It builds, it works, ship it. The "it works" part is obviously skipped by many as well. makeplist now assumes the build is proper, so I'm sure many maintainers do the same. Whatever makeplist (or tinderbox or poudriere the past X years) has been telling them. I've seen only a handful of cases where something didn't build but the build itself passed and hit the plist error. The vast majority of builds do not have this problem. If there is really a file that you are worried won't build, put in a check in post-build to fail if it is missing. Only 1-2 year ago when majority of users were using ports, and not packages, we had the "missing file from build" problem even more so and we survived. When the port just straight installed to /usr/local, nothing did validation of files installed. Evidence for this was when pkg DEVELOPER_MODE came in and we started using poudriere quite often and finding that many ports advertised some file in their plist that did not really exist. If you add globbing, you will get someone using '*' as their entire plist= =2E I strongly believe that autoplist should be the norm for most ports. At work I have been implementing it based on 'make makeplist', and having it auto add in appropriate keywords (not yet upstreamed). This then only requires ensuring DOCSDIR, EXAMPLESDIR are properly set in the Makefile. What might be interesting is an autoplist with glob-like syntax to support sub-packages. So a main package could be everything except =2Edebug, or .h, or man/*. Or each of those prefixed with a keyword specifying with package they are in. I work at an embedded vendor and it would be hugely helpful to be able to easily move symbols, headers, manpages, examples and docs all into 1 or more sub-packages. Doing all of this from bsd.port.mk, optionally, is even better. I really dislike plists as they are today. The argument that having them makes it easy to see what the port installs is bogus. Many don't have pkg-plist because they have PLIST_* or INFO or are missing DOCS/EXAMPLES due to usage of *. Many, such as rubygems and python, have autoplist already. I would like to provide 1 approved way to do autoplist, rather than having the dozens of different implementations that we have today in ports. If you want to see what a package installs, look at the package repository. Pkg has a means to advertise this and we should enable and export it in an efficient way. Portsmon, or Freshports, could potentially feed off this database and display it on their own sites as well. For non-file plist entries such as @exec, these should be in install/upgrade/deinstall scripts. The plist is already a bad place for them. We've been inlining more and more of this and it is far less readable and maintainable in many cases. You have to remember that plist was only born because there was no stagedir (or filemon or install -M). We have a stagedir now. Plist is redundant. Plist maintenance is just busywork for maintainers and portmgr. Orphaned files, leftover files, listed-but-missing, mtree-owned, dependency-owned. All of these go away if we use autoplist. Maintaining ports becomes simpler. Note that I do not propose requiring autoplist, only providing it. If some port has a case where autoplist does not make sense then it does not need to use it. I understand there is fear involved with not having a plist validate everything. Consider that many other package systems do not require a plist to start. --=20 Regards, Bryan Drewery --RBbOvr7EB5b2OgOFL5v2G5Vd1tqieaU6L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUB2SaAAoJEDXXcbtuRpfP7R4IAJE5zLdTod9TLo0ywsfopGII m0UQ8KVfRELYXAdMCSu/KJZOhHjWL2O8IsDdNFusWXAax0zCggWfZW0BPNm76+9l AH8xs2ZiDS7qVsYBHgtKH2Z8DybKtZItwJDw3/SMxhllgk+xaLal4/gchFzX97Lm /Z2nsjgF72U8zETbKAkwS3YBpCKeNuQ7m/pOedSLfnpP7+uHjddFCEjZ6PyJKKN5 ZEQxzlnqaOa2I+7gqGRkQL4xHYelyyVohrY3iFay6CIVfLDgiC1nIG2tJgvEgV6x 3/Dr79N7nxKGvaFnZJx6eNb0d6Ph4jr1to6VvABS35H5MucupY3+LQuk4ZqwN7M= =VToZ -----END PGP SIGNATURE----- --RBbOvr7EB5b2OgOFL5v2G5Vd1tqieaU6L--