User:Mjb/FreeBSD 8 ports management

Here's some general info about this topic.

Get a quick list of installed ports

• with pkgng, pkg info -aoq | sort
• without pkgng, pkg_info -aoq | sort

Using portmaster

Portmaster flags

Some of the most useful flags for portmaster:

• -d will make it delete old distfiles after each port is installed, rather than asking you about it. (-D would make it keep them.)
• -b will make it keep the backup it made when installing the previous version of a port. It usually deletes the backup after successfully installing a new version.
• -x pattern will make it exclude ports (including dependencies) that match the glob pattern.
• --update-if-newer will prevent rebuilding/reinstalling ports that don't need it. But for some reason, you have to specify more than one port on the command-line for this to work.
• -n depends on what else you are doing. Usually it means do a dry run. But in conjunction with -e pkgdbfolder, -s, --clean-distfiles, --clean-packages, --check-depends, or --check-port-dbdir, it means "answer no to all questions."
• --packages will make it use a package (major timesaver) for both the port if the latest package isn't older than the version in the ports collection. Otherwise, it falls back on building the port.
• --build-packages will make it try to use packages for build dependencies... I haven't figured this one out yet. It seems to not be necessary?

Here's an example (to update Perl modules, and Perl if needed):

• portmaster -d --update-if-newer --packages p5-

Update portmaster

Probably a good idea before doing anything else with portmaster.

• portmaster --packages portmaster

Since --update-if-newer needs multiple packages to be specified, we can't use it here. Thus, if there's nothing to update, you will end up reinstalling the same version you already had.

Check integrity of existing ports

• portmaster --check-depends

Delete cached options from previous builds of stale ports

This just does some cleanup of /var/db/ports, which is where the options you chose in the 'make config' step of port building are stored. The options for ports that are currently properly installed will be left alone.

• portmaster --check-port-dbdir

Update ports collection

The ports collection is a folder tree containing Makefiles and patches for 3rd-party software. Anytime you want to add or update 3rd-party software, first make sure the ports collection is up-to-date. Reference: [1]

First time using portsnap or just want a fresh tree? Download the current ports tree to a temporary location (fetch), then install it in /usr/ports, replacing whatever was there before (extract):

• portsnap fetch extract

Not the first time? Download updates to a temporary location (fetch), then apply them to the existing ports tree (update), deleting any modified or added files:

• portsnap fetch update

Now go look at /usr/ports/UPDATING.

See what packages need updating

• pkg audit will tell you which installed packages have security vulnerabilities.
• pkg version -v -l "<" will tell you what installed packages could be upgraded from the packages collection. It's fast.
• pkg version -P -v -l "<" will tell you what installed packages could be upgraded from the ports collection. It's slow.

The upgrade info is based on the info in /usr/ports, not by seeing what's new online.

Some ports will just have a portrevision bump due to changes in the port's Makefile. These are usually unimportant and not worth the pain of rebuilding and reinstalling.

Dealing with port upgrade problems

A port has moved

The Handbook doesn't cover this, but sometimes the ports collection folder for a port that you've installed will get moved.

These moves are listed in /usr/ports/MOVED, which is read by portmaster. So, although you could look at that file beforehand, you probably won't find out about a move until you run portmaster --check-depends, or when you try to update your installed port.

For example, there was once a www/mediawiki meta-port, which pointed to the actual port for the latest stable version. I had used it to install mediawiki119. When I went to update it with portmaster www/mediawiki, I got the following error:

        ===>>> The www/mediawiki port moved to www/mediawiki119
        ===>>> Reason: Rename mediawiki to mediawiki119

The first place to look when you see this message is /usr/ports/UPDATING. Often, there will be a note about it there, with instructions. In this case, though, there wasn't, so I asked about it on freebsd-ports and also on freebsd-doc. I was told that UPDATING will only have unusual things in it, and this particular situation didn't qualify, because the version hadn't actually changed.

I don't think there's a way to just update the list of installed packages so that it will know about the move. You have to want to update the port, and then use portmaster's -o flag to say which new port you want to replace the old one with.

So, for an ordinary move, the answer is:

• portmaster -o NEWPORT INSTALLEDPORT

For example, I could have updated without changing the version:

• portmaster -o www/mediawiki119 www/mediawiki

But since there was a newer version available, I decided to update to it:

• portmaster -o www/mediawiki120 www/mediawiki

lzma library errors

This probably won't come up again, but maybe it will help someone else. After updating to 8.4-RELEASE, I was trying to rebuild the PHP port (as part of the MediaWiki upgrade), but it failed early in the process with this message:

• checking whether libxml build works... no
configure: error: build test failed. Please check the config.log for details.
===> Script "configure" failed unexpectedly.
Please report the problem to ale@FreeBSD.org [maintainer] and attach the
"/usr/ports/lang/php5/work/php-5.4.16/config.log" including the output of the
failure of your make command. Also, it might be a good idea to provide an
overview of all packages installed on your system (e.g. a /usr/sbin/pkg_info
-Ea).
*** Error code 1
Stop in /usr/ports/lang/php5.

Looking at that config.log file, I saw more detail:

• configure:21972: checking whether libxml build works
configure:21999: cc -o conftest -O2 -pipe -march=pentium3 -fno-strict-aliasing -fvisibility=hidden -R/usr/local/lib -L/usr/local/lib conftest.c -lm -lxml2 -lz -liconv -lm >&5
/usr/local/lib/libxml2.so: undefined reference to `lzma_code@XZ_5.0'
/usr/local/lib/libxml2.so: undefined reference to `lzma_properties_decode@XZ_5.0'
/usr/local/lib/libxml2.so: undefined reference to `lzma_end@XZ_5.0'
/usr/local/lib/libxml2.so: undefined reference to `lzma_auto_decoder@XZ_5.0'
configure:21999: $? = 1
configure: program exited with status 1

On a hunch, I decided to see what would happen if I tried to restart Apache:

• httpd: Syntax error on line 108 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache22/libphp5.so into server: /usr/local/lib/liblzma.so.5: version XZ_5.0 required by /usr/local/lib/libxml2.so.5 not defined

When Googling for answers, I found some mention that ports needing the lzma port now need to use the xz port. Something doesn't sound right about that, though, because the xz port is deprecated as well.

It turns out that at some point, the xz port had been installed, needed by some other port. This resulted in some "lzma" libs being placed in /usr/local/lib a very long time ago. Better lzma libs later became part of the base system in /usr/lib. Since the old libs were still sitting in /usr/local/lib, they were taking precedence when other ports needed them. This eventually prevented the PHP port from building, due to its reliance on libxml2, which in turn relies on liblzma, which needs to be up-to-date.

Simply moving the outdated libs out of /usr/local/lib took care of the problem. Specifically, it was /usr/local/lib/liblzma.*. Really, though, the solution is to pkg_delete xz-5.03 (or whatever version you have).

more lzma library errors

While attempting to upgrade all of my installed ports on another occasion in late 2013, the graphics/gd port failed to build because libtool was looking for the nonexistent /usr/local/lib/liblzma.la. A 2011 discussion about it suggested the fix might be as easy as deleting and reinstalling ImageMagick:

• cd /usr/ports/graphics/ImageMagick-nox11
• make deinstall clean install

This just led to the same kind of failure when the build tried to link in ImageMagick's tiff coder. So I tried rebuilding the underlying lib first:

• cd /usr/ports/graphics/tiff
• make deinstall clean install

Then I went back to the ImageMagick build:

• cd /usr/ports/graphics/ImageMagick-nox11
• make

That got me past the tiff coder error, so I continued:

• make install

That worked as well.

ImageMagick's enormous set of dependencies and lengthy build process have been problematic for me in the past. I'd rather exclude it from any port upgrades, but I'm not sure it's possible or wise to do so.