Using ~/.blueprintignore

The ~/.blueprintignore file is all about keeping your blueprints small and focused.  Blueprint already does a lot to reduce noise but every system is a little different and every user has a different workflow.  Use ~/.blueprintignore to tailor Blueprint to your exact specifications.

If you’re familiar with version control software like Subversion or Git, you’ll hopefully feel right at home ignoring particular files.  If not, consider a program’s source code under version control.  The Makefile, source code, and documentation should all be versioned but the compiled binary shouldn’t — it can always be rebuilt from the source code.  Listing the binary in the .gitignore file will prevent Git from versioning it (other version control software works similarly).

Blueprint inspects a running system and collects packages, configuration files, and source installs.  It ignores essential packages and files that are unchanged from their packaged versions but it errs on the side of caution so it isn’t always as succinct as possible.  This is where ~/.blueprintignore comes in.

Syntax

Each line in ~/.blueprintignore is potentially a rule.  Blank lines or lines that begin with # are ignored when ~/.blueprintignore is parsed.

Rules have the following structure:

:type:resource

type is one of file, package, or source and each of these types treats resource a little differently.

file

file resources name a pathname or filename pattern to be ignored.  If the resource begins with a /, it is treated as an absolute pathname.  If the resource contains a / elsewhere, it is expanded relative to /etc.  Directory resources also apply to files within the directory.  If the resource does not contain a /, it is matched against the filename component of files encountered.  In all cases, standard glob(7) patterns are allowed.

Typically, file rules are written without the :file: prefix: :file:/etc/foobar is typically written as /etc/foobar.

package

package resources have the following structure:

:package:manager/package

manager is the name of a package manager as it appears in a blueprint, such as apt, yum, rubygems1.8, ruby1.9.1, python2.6, pip, or php-pear.  The list of possible managers is not fixed so consult a blueprint created on your system to see what’s in use:

blueprint show my-first-blueprint | less

package is the name of a package managed by manager or * to ignore them all.  When a package is ignored, it automatically ignores all its dependencies, too.

source

source resources have the following structure:

:source:pathname

pathname must be a fully-qualified pathname to ignore when searching for source installations (for example, in /usr/local).

Negating rules

Any rule may be prefixed with a ! to negate its meaning.  If a resource matches more than one rule, the last rule to match determines if the meaning is negated.  For example:

!/etc/foobar
!:package:apt/funny-manpages
!:source:/opt

When a resource is unignored, it is included in blueprints even when it otherwise wouldn’t be.

When a package resource is unignored, it does not affect the package’s dependencies.

Examples

Cherry-picking configuration files

Some packages place a large number of configuration files in /etc without giving Blueprint any way to detect them.  Ignoring all but a select few is easy:

/etc/nagios3
!/etc/nagios3/conf.d/my-*.cfg

Eliminating noisy dependencies

Packages can bring along a lot of baggage.  To reduce a blueprint to just the main package in a large dependency tree, ignore it and unignore it immediately:

:package:apt/build-essential
!:package:apt/build-essential

Include source installs from outside /usr/local

Many users prefer to build and install non-standard software in /opt, which Blueprint can now accommodate:

!:source:/opt

Reference

blueprintignore(5) is always available online or on a system with Blueprint installed.