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 /usr/ports/Mk/bsd.ports.mk. 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. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature