From owner-freebsd-questions@freebsd.org Tue Jul 14 08:50:47 2015 Return-Path: Delivered-To: freebsd-questions@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 4FC3C99C194 for ; Tue, 14 Jul 2015 08:50:47 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C711D27D for ; Tue, 14 Jul 2015 08:50:46 +0000 (UTC) (envelope-from matthew@freebsd.org) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t6E8oXF2033657 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 14 Jul 2015 09:50:40 +0100 (BST) (envelope-from matthew@freebsd.org) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t6E8oXF2033657 Authentication-Results: smtp.infracaninophile.co.uk/t6E8oXF2033657; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <55A4CD4E.3040003@freebsd.org> Date: Tue, 14 Jul 2015 09:50:22 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Naming a locally-built version of a package References: <37E1F657-243D-4F8F-A563-0C17B344D1B9@omnigroup.com> In-Reply-To: <37E1F657-243D-4F8F-A563-0C17B344D1B9@omnigroup.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cekIi6qv51EPlEIVrr1iCWlU2Xw1RJpWb" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:50:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cekIi6qv51EPlEIVrr1iCWlU2Xw1RJpWb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/14/15 01:19, Wim Lewis wrote: > Is there a particular recommended practice for naming a > locally-built package that is built with a local patch, or different co= nfigure > options, etc., so that it works well with the rest of the package > system, particularly dependencies and things? If what you're doing is tweaking an existing package built out of the ports tree, then mostly people wouldn't bother giving it a special name. It's just a locally built version of the 'foobar' package. However, it is perfectly feasible to create your own ports and overlay on the ports tree. You can add a Makefile.local at pretty much any level of the tree so you can add Makefile-foo to an individual port (eg. to add new options or similar). Similarly you can add your own ports or even entire new categories of ports. For the sort of thing you want to do, you would probably want to create a slave port with the original as master -- which is certainly the way to go if you happened to want to build both modified and unmodified versions of the port. > Ideally: let's say I'm building a custom version of Foo-1.3. I'd like t= o name it such that: > - Existing packages that require Foo will be satisfied by my patched= Foo > - Local packages which require my patched Foo can specify a dependen= cy on it This is much harder. Dependencies are registered against the PKGNAME of a port, and that is required by pkg(8) to be unique across the ports tree. You'ld probably have to modify all the dependent ports to change their RUN_DEPENDS or LIB_DEPENDS settings to point to your modified port.= As I said above, usually people just use the original port name with their own modifications, and it's mostly because of dependency tracking like this. There was discussion at BSDCan about introducing 'flexible dependencies' -- which is essentially a list of packages (including version number ranges) that could be used to fulfil a dependency, but even so, you'ld still have to add your custom ports to that list. > Less important but nice: > - pkg audit will still recognize my Foo as Foo and inform me of thin= gs I should know > - The system won't suggest to "upgrade" my Foo to a non-patched Foo = of a later version=20 >=20 > Is this (or a subset) possible with pkgng? pkg audit matches against the PKGNAME as I recall, so doubtful that it would alert you to security problems in your modified package. However, it is certainly possible to tell pkg(8) not to mess with locally customized packages. See pkg-lock(8). The mechanism is not entirely as smooth as we would like it to be, and pkg(8) should grow the intelligence to understand that replacing a package 'Foo with option bar' with a package 'Foo without option bar' is something that should be avoided wherever possible. Cheers, Matthew --cekIi6qv51EPlEIVrr1iCWlU2Xw1RJpWb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVpM1YAAoJEABRPxDgqeTnuUAP/it/0EDbPDeZDOkM8PR6ejPU BAqcAVmm0aYDwk3/CnMXAjWbVhC1yJZEXyjf9Z7TFUg7q/8NrI9rNSgJiW3hOvp0 ulO+KJc4l4jnwzo+d8D7NjOrqFUEosafeo1xCTqIb9EZmFoxlYJTM4rJUpdv6U0U m8SmpjAAzH+rFFhlnewjo4vYWi3P+J2i/iR0ZtWhy1V3BbbZJscpWd6Lu56L5jeH lV+kRfiNjjZDkYT5kaQpohpaGC/GqhuorENjTyH9pVPsm+w7aNtf0jodr9WXT/1M ppXGH4ROU119sDdJS4c1U48GP9cxc6O7733uLtoJhT8jOT4vtGre1RCAmetS6Zyc 0wkvWAdFyH9Gm9huLCWIj3one4h9fBsK0fJcupGJUtuqSMUqxavy+uTGuDn+SQBN sxLr5epcO9SIFOjmZbfdWK2dNDwbOcWFnKNN9Tk9v1PyYxMQmP5aaTFV0VYxmdQp n9ZGUXTpYFyaQhX39EC+EXjYh99VzJHX+qhbzuE4qhGV2kqOz6MuGWLZG9prIfeN qJj23O9E9w+kC91on2knmRFJz8Q+eJuOBTcwmeNIxD/phMv8ArZUTca/HR8ShfSR e9UhQlI5J/2FE2UFyTBD7aMxYIVhxgSd/JVLFcuzbwRzFR7EFoRqMNRde8pNEJcQ Ns5EY7zpCIZm3jc5dXYY =kwJQ -----END PGP SIGNATURE----- --cekIi6qv51EPlEIVrr1iCWlU2Xw1RJpWb--