third-party ports/packages sources

Matthew Seaman m.seaman at
Wed Oct 6 21:19:10 UTC 2010

On 06/10/2010 19:06:01, Chad Perrin wrote:
> Is there some way to set up a third-party online source for ports and/or
> packages that allows users to do the same kinds of things they can do
> with the official ports system?  I mean, for instance, using portversion
> to check whether there are new versions available (or an equivalent
> operation) and possibly even checking for security issues via portaudit.
> I see, looking at the manpage for portversion, this:
>      PKG_DBDIR      Alternative location for the installed package database.
>                     The default is ``/var/db/pkg''.
>      PORTSDIR       Alternative location for the ports tree and the ports
>                     database files.  The default is ``/usr/ports''.
> I also see some stuff in pkgtools.conf comments that might pertain to
> this sort of thing, but I'm not entirely clear yet on how this might be
> used to access a third-party repository for ports without breaking normal
> operation.  If there's a tutorial out there that would explain how to do
> something like this, I have not yet found it.

You certainly can do this sort of thing.  If you want to create a local
pkg repository all it is basically is a HTTP or FTP server wrapped
around the file structure generated by 'make package' under
/usr/ports/packages.  Maybe with some extra depth in the path to account
for CPU architecture and OS version.  You can mirror pkgs from the
official sites or you can compile your own -- in which case, check out
the Tinderbox application.  Then you just need to set some environment
variables such as PKG_PATH, PACKAGEROOT or PACKAGESITE so that the
various client-side tools will use your personal pkg repo.  See the
ENVIRONMENT section in pkg_add(1).

Now, you could create your own entirely independent ports tree if you
felt that way inclined, but why would you want to?  Most freely
available software is already available from the ports, and you don't
want to duplicate the maintenance burden of any of that.  Instead, a
better approach is to use the hooks provided within the ports system to
add your own local patches, add extra ports or even entire extra
categories of ports to the standard tree.  The key point here is that
you can create a Makefile.local at any level in the ports tree and it
will be included by the regular ports Makefile at that level.  There are
several other potential Makefile filenames you could use similarly,
which the ports looks for and will include given various criteria: the
best way to learn about them is to study the code in

If your local ports are any good, then do submit them for inclusion in
the main ports collection.  Pro bono publico as lawyers quite rarely say.

You have to be a bit careful with updating mechanisms if you customise
your ports like this: portsnap for one is quite unfriendly to "foreign"
files within the ports tree, but csup works fine.

Portaudit is a bit harder -- it's processed out of the vuxml sources
automatically, and there isn't a simple mechanism for adding local
modifications.  You could duplicate the whole portaudit generation
process with some local tweaks if you needed to, but on the whole I
think just using the centrally generated version would be good enough
for the vast majority of people.



Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
JID: matthew at               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url :

More information about the freebsd-questions mailing list