Ports overlay

Matthew Seaman m.seaman at infracaninophile.co.uk
Sun Mar 7 09:47:23 UTC 2010

Hash: SHA1

On 07/03/2010 08:45:41, CyberLeo Kitsana wrote:

> By necessity and convenience, I have developed a series of additions and
> changes to the ports tree. These changes are probably not worthy of
> inclusion into the official tree, so I'm looking to maintain an overlay,
> of sorts, in the spirit of Gentoo's overlay capability.
> Is there an official method of hooking changes into a ports tree, while
> maintaining the ability to csup or portsnap the unmodified version? How
> do others tackle this particular problem?

Yes, you can add your own local ports or even whole categories of local
ports without too much difficulty.  You can even add some tweaks to an
existing port -- you don't have complete freedom to do anything there,
but you can do quite a lot.

If you create a Makefile.local at any level in the ports tree it will be
included alongside the usual Makefile.  This means you can override a
lot of the available settings at will.

So, if you create /usr/ports/Makefile.local

with the contents:


then you can create a directory /usr/ports/myports and put your own
ports inside it -- you'll need a /usr/ports/myports/Makefile just like
the other category directories.

Similarly, if you prefer to mix your own stuff more intimately with the
rest of the ports tree, you could create /usr/ports/devel/Makefile.local
with the contents:


and then create /usr/ports/devel/{myfunkyport,myotherport}

Finally, you can put a Makefile.local into a port directory, and use it
to override settings specific to that port.  This is probably not very
useful except in limited circumstances.  Another handy thing to do is
create eg. file/patch-foo to contain local patches against the upstream

Makefile.local is intended for local customizations like this, but there
are also Makefile.inc and Makefile.${ARCH}, Makefile.${OPSYS},
Makefile.${OPSYS}-${ARCH} which will similarly be automatically included
if present (and if the ARCH and OPSYS settings match.)

Now, all of this is at risk of clashing with future updates to the ports
tree -- you're going to have to maintain it yourself, and cope with
ports being deleted or moved around.  Creating your own separate
category as shown first will give you the best separation and probably
the least maintenance hassles.

If you want to modify an existing port, probably the best approach is to
create your own slave port -- see the docco on MASTERDIR in the Porter's
Handbook and look at eg. games/freeciv-nox11 for about the simplest
possible example.  It's not fool proof -- some modifications will always
need support in the master port's Makefile, but there's a lot you can do
without that.

Because this entails inserting files into the ports tree, you need to
take some thought as to how to avoid wiping out your changes when
updating the ports tree.  Extra files are generally ignored by csup(1),
but portsnap(1) will blow them away.  You could get creative using
unionfs (see mount_unionfs(8)) or you could go for the option of
maintaining a local CVS repository with your mods on a separate branch.



- -- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the freebsd-questions mailing list