Naming a locally-built version of a package

Matthew Seaman matthew at
Tue Jul 14 08:50:47 UTC 2015

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 configure
> 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 to 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 dependency 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 things I should know
>    - The system won't suggest to "upgrade" my Foo to a non-patched Foo of a later version 
> 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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the freebsd-questions mailing list