Home > FreeBSD > FreeBSD Ports: Managing Custom Ports/Physical Categories

FreeBSD Ports: Managing Custom Ports/Physical Categories

December 16, 2013 Leave a comment Go to comments

Managing Custom Ports/Physical Categories

Overview

This post describes a method of managing custom FreeBSD Ports involving creating a directory (a.k.a. a physical category) of subdirectories; Each an individual port containing necessary files, e.g. Makefile, etc.

I found this process, documented in the FreeBSD Committer’s Guide, to be confusing as the answer provided does not directly address the question. It describes moving a port as opposed to creating a new category/port, but it does encompass this process. Therefore, the answer is unclear and contains superfluous information.

We simplify the instructions for creating physical categories to augment the instructions for moving a Port. I assume the reader has previously prepared a port which exists on disk. Creating a port and working with version control systems is beyond the scope of this post.

Please bear in mind, My Git-fu is rudimentary at best. If others, more knowledgeable in this area, can comment on other ways to accomplish the same, please do.

The Use Case

Engineers and administrators deploying custom software may wish to build and distribute packages for these applications via FreeBSD’s Ports system. There are two options for using Ports; We will be addressing the latter in this post:

  • Submit to the official FreeBSD Ports collection
  • Create an internal custom Ports collection

The Procedure(s)

We start by cloning FreeBSD Ports from GitHub and pulling a customized Ports collection (maintained internally) into our local FreeBSD Ports repository. We’ll finish by describing the process for pulling updates into the custom tree from each of the two repos.

Creating The Repo

  1. git clone https://www.github.com/freebsd/freebsd-ports.git
  2. cd freebsd-ports
  3. git remote add repo /path/to/local/repo
  4. git pull repo master
  5. cd $new_physical_category/$custom_port && make describe (optional, reports errors if they exist)
  6. run portlint on the port (Verifies correct state of Port)
  7. env PORTSDIR=/path/to/ports sh -e /path/to/ports/Tools/scripts/chkorigin.sh
  8. cd /path/to/combined/ports_tree && make checksubdirs && make index

Updating the Repo

  1. cd /path/to/local/freebsd-ports/clone
  2. git pull origin
  3. git pull repo master

If new physical categories and/or ports are added to the internal repo, steps 5 – 8 above need to be executed. Other changes may or may not require this.

Summary

This procedure creates a combined Ports collection from two sources, FreeBSD’s official Ports collection and a private collection. Once completed, normal operations can be performed on the resulting Ports tree as necessary such as installing applications or creating packages, etc.

One use of this repo is to commit to git and tag each commit as a new version of the custom Ports collection thus making them easily recallable.

Disclaimer

Data and information described on this blog are for informational purposes only. The author of this blog provides no warranty/guarantee, expressed or implied, that this data and information will function as described here. Readers are expected to exercise due diligence when researching, developing, and deploying techniques and methods for use within their environments.

Comments posted are the explicit opinions of the comment poster themselves and does not necessarily reflect the views and opinions of the author of this blog.

About these ads
Categories: FreeBSD
  1. December 17, 2013 at 12:42 AM

    There is no need to have this repo sit anywhere special – you can have it at /usr/ports – even if you run portsnap and overwrite some of it, the .git dir will remain so you can revert any overwrites. Personally I prefer to keep the master branch equal to official ports and use myports branch for my mods. git checkout master git pull git checkout myports git merge master – this lets you diff to master to see all changes you have made.

    • December 24, 2013 at 2:09 PM

      I figured this would happen :) I publish a blog post which links to a specific location in the Committer’s Guide where I criticize the content and not long after, the link is no longer valid, but still does link to the Commiter’s Guide. FreeBSD’s doc team has been very energetic about rebuilding the site’s content.

      Thanks, Shane! That seems to be a simple solution. I’ll give it a shot.

  2. November 23, 2014 at 6:40 AM

    Thank you. :)

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 257 other followers

%d bloggers like this: