these entries are mandatory, and there are many other possible entries in port Makefiles, but these are fairly common. The PORTNAME (v) is the name the software uses in FreeBSD’s ports system. This is not necessarily the same as the software name, as we saw earlier in our search for Midnight Commander. The PORTVERSION (w) is the version number of the software, as given by the software’s author. CATEGORIES (x) lists all the ports directories where the port can be found. For example, this port is under /usr/ports/security. MASTER_SITES (y) contains a list of Internet sites where the software can be found. This is where the ports system tries to get the software from. If one site is unreachable, it tries the next. The DISTNAME (z) is the name of the original file of software source code. The ports system tries to grab this file from the MASTER_SITES given earlier. The MAINTAINER ({) is the person responsible for maintaining the FreeBSD port. This person doesn’t actually write the software, but just makes sure that it installs on FreeBSD. GNU_CONFIGURE (|) tells the ports system if the software needs to use the classic GNU program autoconf. In a related entry, CONFIGURE_ARGS (}) lists arguments to be given to autoconf. There is usually a list of man pages that the program installs (~). You can check these pages with man(1) to see how to use the program. You might then see a bunch of “if defined” statements like this one: ………………………………………………………………………………………. .if defined v (WITH_FLEXRESP) BUILD_DEPENDS w += ${LOCALBASE}/lib/libnet.a:$ ? {PORTSDIR}/net/libnet CONFIGURE_ARGS +=–enable-flexresp CONFIGURE_ENV += CPPFLAGS=”-I${LOCALBASE}/include” LDFLAGS+= “-L${LOCALBASE}/lib” .endif ………………………………………………………………………………………. This is a build option for the port. The first line in this example is the variable (v) you need to set in this case, WITH_FLEXRESP. The second line shows that this adds a dependency (w) for the port, /usr/ports/net/libnet. The remainder is a bunch of software-building commands that are altered by setting this variable. You set this variable on the command line. To set WITH_FLEXRESP, you would type ………………………………………………………………………………………. # make install WITH_FLEXRESP=YES ………………………………………………………………………………………. You don’t need to understand the balance of this listing right now, but notice the little question mark (?) and plus and equal (+=) symbols scattered throughout it. These mean that you’re adding commands to the build process, literally changing how the software is built just by setting this 242
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
corrupted, this step will detect it and stop the build with a warning about a checksum mismatch. If the distfile has been deliberately changed, make checksumstops compilation. NoteSoftware authors sometimes make minor changes to their code, but give the source file the same name as when they first made it available for download. The FreeBSD port might or might not work after this change. If you’re sure that the distfile has not been compromised or corrupted, and want to use it despite this warning, you can override this with make NO_CHECKSUM=YES. I highly recommend that you check with your vendor to see if this is a legitimate change. Make Depends The make depends stage checks to see if the port is dependent on any other software, and, if so, whether that software is installed. (For example, an X window manager requires an X server.) If the software on which the port depends is not found, this stage recurses through the various dependencies and completely builds them all. Make Extract Once you have the port distfiles, you have to uncompress and extract them. This is done under a work directory in the port. To create this directory and uncompress the distfiles under it, use make extract. Make Patch The make patch stage applies any FreeBSD-specific patches listed in the Makefile to the port. Make Configure Next, make configure checks to see if the program needs a configure script. If it does, it runs it. If not, the port build proceeds silently to the next step. Make Build The make buildstage compiles the checked, extracted, and patched software. Make Install Finally, make install installs the software and records its presence under /var/db/pkg. Make Target Dependencies Each make target depends on the make targets before it. You cannot patch source code that you have not yet fetched, for example. Whenever you use any make target, make runs all previous stages that have not yet been run. For example, make extract performs a make fetch, make checksum, and make extract. How might you use these make stages in practice? Say that you want to apply some patches to a program before you compile it patches that address stability or security problems. You want to apply the patch to your source code after you’ve extracted it and applied the FreeBSD-specific patches. To do so, you could run make patch, apply the new patches to the software under the work directory according to the vendor’s instructions, and then return to the port directory and type make install. Built-In Port Features Ports allow you to do a great deal of customization, which you can read about in the port’s Makefile. Since the port’s Makefile includes specific instructions for building this particular piece of software, it’s where options for that software are most likely to be found. Many ports announce additional features when you first type make install, though not all will work (especially some older ones). Whether a feature will work depends on the port maintainer’s skills, time, and inclination remember, this is a volunteer project! 240
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
………………………………………………………………………………………. # pkg_add -f packagename.tgz ………………………………………………………………………………………. You’ll see a warning that a dependency was not found, but that the install is proceeding anyway. If the software works, great! If not, uninstall it and start working with ports. [3]No, Microsoft Word is not available on FreeBSD. Yet. But it’s very difficult to think of a major, recognizable example of binary-only software for FreeBSD, as almost all of it is available in source form. Using Ports It takes longer to build software using ports than it does when using packages, and the ports system requires a live Internet connection. Still, the ports system can produce better results than packages. Let’s take a look at a port. We’re going to pick on one of my favorite security tools, SKIP.[4] ………………………………………………………………………………………. # cd /usr/ports/security/skip # ls v Makefile x distinfo z pkg-comment | pkg-plist w README.html y files { pkg-descr } scripts # ………………………………………………………………………………………. The Makefile in the preceding list (v) contains the basic instructions for building this port. If you were to take a look at this file, you’d quickly notice that there isn’t much in it. The Makefiles for individual ports don’t contain much beyond some basic information about the port; they don’t have information about how to build FreeBSD software in general. (Most of the FreeBSD ports Makefile system is contained in the directory /usr/ports/Mk; editing these files is a very advanced topic, and you really don’t want to go there until you’re very comfortable with Makefiles.) The README.html file (w) gives a brief description of the port. If you’re using a Web browser to skim the ports collection, you’ll be directed to this file when you ask for information on this port. The distinfo file (x) contains integrity-checking information (or checksums) for the files required to build this program. The files directory (y) contains any add-on files required to build this port. Our particular example requires 87 patches, but many ports don’t even have a files directory, and build cleanly without patching. The pkg-comment file (z) contains a one-line description of the port. Similarly, pkg-descr ({) contains a longer, more detailed description and (usually) a URL for more information on the program. The pkg-plist file (|) holds a list of all the files installed by the port (the “packing list”). If a file is not listed here, it will not be installed. 238
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Finally, the scripts directory (}) holds a variety of scripts to be run at various stages of the port-building process. This directory might or might not exist if the port builds without any special tweaking, it won’t have any additional scripts. These scripts perform any pre- or post-processing that the port needs, for example, changing permissions on a downloaded distfile so that patch(1) can run properly. Combined, these files create the tools and instructions needed to build the software. Installing a Port If you’re familiar with source code, you’ll quickly notice that there is no actual source code in the port. Sure, there’s patches to apply to source code, and scripts to run on source code, but no actual source code! You might rightly ask just how this is supposed to work without the source code. When you activate a port, your system automatically downloads the appropriate source code from an approved Internet site. It then checks the downloaded code for integrity errors, extracts the code to a working directory, patches it, builds it, installs everything, and records the installation under /var/db/pkg. If the port has dependencies, and those dependencies aren’t installed, it will interrupt the make process to build those dependencies, and then finish its own. To trigger all this, you just have to go to a port directory and type this command: ………………………………………………………………………………………. # make install ………………………………………………………………………………………. When you do, you’ll see lots of text scroll down your terminal window, ending with a “recording installation” message. This all-in-one installation process handles any changes in dependencies. If a port requires another program, the port will simply gloss over minor changes in that program. For example, perhaps you have a version of Apache that’s a few months old. A package would demand that you install the newer version, while a port will just check to see if Apache is installed. As you grow more experienced with building source code, however, you’ll find that this all-in-one approach isn’t appropriate for every occasion. Not to worry; the ports system gives you the opportunity to take the port-building process exactly as far as you like, because make install is actually not one but a series of commands. Using Make Install The make install process starts with make fetch. During this stage of the process, make checks to see whether the source code is in /usr/ports/distfiles. If it’s not, your system goes to get it. Make Fetch The make fetch process first checks for the source code in the MASTER_SITE listed in the Makefile, then checks a list of backup sites provided by the ports system itself. If it finds the source code, it downloads it, and that downloaded source code is called a distfile. Make Checksum Next, make checksum confirms that the distfile’s digital signature matches the one that the port has in the distinfo file. This is a security measure; if the FTP server was broken into by a malicious hacker and the source code replaced by a Trojan horse, or if the download was 239
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
the port itself was slightly changed; for example, the build process for the FreeBSD port of WindowMaker 0.65.0 has been updated once. (Often these changes are purely internal, and don’t affect the software’s behavior or performance.) If you’re running a FreeBSD release and only installing software from the CD or the version released with your release, this interdependency isn’t much of an issue. After all, the packages built for a release do not change. You might be running an older version of FreeBSD, but want a program that was just released. You might be continually upgrading your system, and have older versions of software. For example, the package wmakerconf-2.8.1 requires windowmaker-0.65.0_1. That’s fine if you have the right package installed, but if you have installed windowmaker-0.65.0 or windowmaker-0.65.0_2, pkg_add will think that you don’t have the proper required package installed and will go grab the appropriate WindowMaker. This takes up disk space at best, and overwrites existing software at worst. One way around this problem is always to use packages from the same date or time. (If you set the PACKAGESITE environment variable to the packages directory for a particular FreeBSD release, you’ll always have matching packages.) This is perfectly acceptable in many cases, since you don’t always need the latest version of a piece of software when a version just a month or two older will work just fine. In other cases, this practice isn’t acceptable because an older version might have security problems or performance issues. In that case, I recommend you use ports instead. Rather than checking for installed programs by the name of the package, ports check for the existence of the program itself. To continue our earlier example, the port for wmakerconf won’t check for WindowMaker version 0.65.0_2, it will just look for a program called “window-maker.” This makes ports much more flexible. Forcing an Install There will be times when you want to use a package where a dependency has changed, and you don’t want to upgrade the dependency or use an older package. Don’t do it. Programs can crash, badly, if you do. Still, it is possible to force an install if you want to after all, dependency changes are frequently minor and do not affect program behavior. The hard part is verifying that your programs will be okay. Note Before you read further, let me say that you should not be doing this. If you’re in this situation, use a port instead. It will take longer, but things will almost certainly work correctly. If this isn’t possible, read on. Should you consider forcing an install? Well, as a very general rule of thumb, if the package name has changed by either adding a trailing underscore and a number, or if this trailing number has been incremented, the package may work. This is no guarantee, mind you, and if things start breaking, you’ll have to uninstall the package and do things correctly. To force an install, first, manually grab the package you want to use. (Be sure you don’t have a packages CD-ROM mounted you don’t want the system to go looking for matching dependencies and install them, overwriting your existing software and causing problems.) Once you’ve grabbed your package, run pkg_add -f:: 237
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
………………………………………………………………………………………. # pkg_info -aR Information for Hermes-1.3.2: Required by: windowmaker-0.65.0_1 wmakerconf-2.8.1 Information for JX-1.5.3_1: Required by: libjtree-1.1.7_1 libjtoolbar-0.5.4_1 code_crusader-2.1.4_1 … ………………………………………………………………………………………. To find out the space needed by the files within a package, use pkg_info -s packagename. (Note that this only includes files installed by the package; files created by the package are another matter entirely. After all, do you count your text files and email messages as part of your office suite?) Another common question is which package a file came from. You might be browsing through /usr/local/bin and come across a file that you don’t recognize, haven’t used, and have no idea why it’s there. Use the -W flag to pkg_info to perform a sort of “reverse lookup” on files to see which package they came from: ………………………………………………………………………………………. # pkg_info -W /usr/local/bin/xwe /usr/local/bin/xwe was installed by package xwpe-1.5.22a # ………………………………………………………………………………………. Controlling Pkg_add You can use shell-environment variables to control how package-handling tools behave. PKG_TMPDIR The PKG_TMPDIR environment variable controls where pkg_add will unpack its temporary files. A package is a tarball with some added instructions on how to install things. To install a package, you have to untar it. If you’re short on space in the standard directories that pkg_add tries to use, the untar will not finish and the install will fail. By default, pkg_add tries to use the directory given by the environment variable $TMPDIR. If that variable doesn’t exist, pkg_add checks for room in /tmp, /var/tmp, and /usr/tmp, in that order. You can set PKG_TMPDIR to make pkg_add use a different directory, where you do have room: ………………………………………………………………………………………. # setenv PKG_TMPDIR /usr/home/mwlucas/garbage # ………………………………………………………………………………………. 235
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
(You can add this line to your .cshrc to have it set every time you log in.) PACKAGEROOT The PACKAGEROOT environment variable controls the FTP server used by pkg_add’s automatic package fetching. By default, pkg_add -r tries to download everything from ftp.FreeBSD.org, the default server. However, you can frequently get better performance by manually choosing a closer, less heavily used mirror. Set this PACKAGEROOT with a particular server name and protocol as a URL. For example, to download from ftp3.FreeBSD.org, enter this: ………………………………………………………………………………………. # setenv PACKAGEROOT ftp://ftp3.FreeBSD.org # ………………………………………………………………………………………. PACKAGESITE PACKAGESITE, another popular environment variable, gives an exact path to check for a package repository. You might choose to use this if you want to use packages from a particular release, or if you have a local package repository. (We’ll discuss setting up a local package repository in the Building Packages section, later in the chapter.) Set the PACKAGESITE variable as an absolute URL: ………………………………………………………………………………………. # setenv PACKAGESITE ftp://ftp4.FreeBSD.org/pub/FreeBSD/releases/4.4- STABLE/packages/All # ………………………………………………………………………………………. Package Problems The package scheme seems like a great system, right? Well, sort of. There are a few problems, specifically lags in the software-porting process and the software-synchronization requirements. The overwhelming majority of packages is software produced by third parties, folks who release their software on a schedule completely independent of FreeBSD. When they release an updated version of their software, the FreeBSD package is updated. There is a delay between the release of an original software package and the port to FreeBSD. A popular port might be updated in hours, while large or less frequently used ports can languish at an older version for days or weeks. Also, packages are interdependent, and many rely upon others in order to function properly. When the FreeBSD ports team changes a package, that change cascades through all the dependent packages. That’s why you’ll see packages with names like windowmaker-0.65.0_1. The _1 shows that a program the package depends on has changed, and so this version of WindowMaker is slightly different than the previous version. These bumped version numbers might also indicate that 236
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
Uninstalling Packages Use pkg_delete(1) to uninstall packages: ………………………………………………………………………………………. # pkg_delete openuniverse-1.0.b3 # ………………………………………………………………………………………. If you want to uninstall a package required by other packages, only do so when you know exactly what you’re doing, and why. (For example, you might want to upgrade a dependency package to a newer version.) Don’t expect software that requires this package to work once you’ve uninstalled it, however! You can use pkg_delete -f to force an uninstall. Pkg_delete will warn you, but will do it anyway. Package Information Uninstalling works well when you remember the exact version number of every package you’ve installed. If you can do that, I commend you. If you’re like me, though, you’re lucky to remember that you have a piece of software installed on a system, let alone which version it is! FreeBSD includes pkg_info, a tool to examine installed packages in a more convenient manner than manually scanning /var/db/pkg. Pkg_info(1) uses the contents of /var/db/pkg to do its work, but automatically handles a lot of boring manual searching and sorting for you. When it is run without any options, pkg_info lists each package installed on your system, along with a brief description of each: ………………………………………………………………………………………. # pkg_info Hermes-1.3.2 Fast pixel formats conversion library JX-1.5.3_1 A C++ application framework and widget library for X11 Mesa-3.4.2_1 A graphics library similar to SGI’s OpenGL ORBit-0.5.8_1 High-performance CORBA ORB with support for the C language XFree86-aoutlibs-3.3.3 XFree86 a.out compatibility libraries … ………………………………………………………………………………………. As you can see, this output will give you the name and version of each package you’ve installed, so you can uninstall it easily. Package Info Arguments You can use various arguments with pkg_info to gather other information about the packages on your system. When you start using arguments, pkg_info requires either a package name to investigate or the -a flag, which means “for all packages.” For example, to learn which packages on your system require other packages, you would use this option: 234
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
its CD-ROM sets and can’t possibly fit all 6,000-plus packages onto 4 disks! Also, software on CD is built for a particular release of FreeBSD. Having a CD-ROM of packages for version 4.4 won’t help you if you’re running FreeBSD 4.6. Too, if you’re tracking -stable, the packages on the CD are slightly out of date, and you should grab the latest package from ftp.FreeBSD.org. (You must have a live Internet connection to do this!) If you know the full package name and version number, you can get the latest package from the FreeBSD FTP site automatically, like so: ………………………………………………………………………………………. # pkg_add -r xearth Fetching ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4.4- release/Latest/xearth.tgz… Done. # ………………………………………………………………………………………. The advantage of this is that the system will automatically find the proper FTP location, download the proper version of the package and all dependencies, and install them all. The downside is, you have to have a live Internet connection. This method is also less secure than installing from CD. While the packages on the CD set have all been inspected and verified to be what they claim to be, the packages on the FTP server could have been tampered with by a malicious hacker. You could be installing Trojan horses, or worse. (This has never happened, mind you, but it is theoretically possible.) You can also manually download packages from an FTP site of your choice. (We discussed finding a convenient FTP server in Chapter 1.) To do so, find a convenient FTP site and log in to that server. Then, if you’re running a -release, go to pub/FreeBSD/release and into the directory for your version of -release. If you’re tracking -stable or -current, go to pub/FreeBSD/ports and choose the directory for your -stable or -release. Once in the appropriate directory, you’ll see a directory tree much like that under /usr/ports. Now, just find your package and download it, then install it via the command line: ………………………………………………………………………………………. # pkg_add openuniverse-1.0.b3.tgz # ………………………………………………………………………………………. Note This method will not automatically install dependencies. It’s most useful for times when you’re behind a firewall and must jump through some hoops to download files from the Internet. What Does a Package Install? Now that your software is installed, how do you find it on your system? There’s no Start menu, after all! Not to worry. 232
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
For a complete list of what a piece of software has installed, see /var/db/pkg. This directory contains a complete list of every port or package you have installed on the system, and what each set of software contains. For example, our /var/db/pkg now contains a directory called openuniverse-1.0.b3. If you look in that directory, you’ll see the following: ………………………………………………………………………………………. # ls /var/db/pkg/openuniverse-1.0.b3/ #NAME? # ………………………………………………………………………………………. The +COMMENT file is a brief description of the package; +DESC contains a longer description of the package. The interesting file is +CONTENTS, which lists every file installed by the package. This file is quite long, but we’ll look at the start of it. ………………………………………………………………………………………. # more /var/db/pkg/openuniverse-1.0.3b/+CONTENTS v @name openuniverse-1.0.b3 @cwd w /usr/X11R6 x @pkgdep jpeg-6b @pkgdep Mesa-3.4.1 @comment y ORIGIN:astro/openuniverse z bin/openuniverse @comment MD5:2a4775c079a589e78cf54be5444316cb share/openuniverse/data/stars.dat @comment MD5:eee6bb0caf1ae32bc2ff043e7baee17a share/openuniverse/data/messier.dat @comment MD5:acd357ee82d95121fbf42ba9982f1dd8 ………………………………………………………………………………………. The first line (v) is, of course, the name. Following that is the directory tree where the package was installed (w) after the cwd keyword. You can see that openuniverse is installed under /usr/X11R6. The pkgdep keywords (x) are other packages that this package depends on. The ORIGIN comment (y) is the category in the ports tree where this package was created. Finally you have the list of files (z). Each file installed by this program is listed here, along with its MD5 checksum. (The various package-handling tools use the MD5 checksum to verify that a file is still good and that it hasn’t been damaged during transit or by operator error.) Each file is listed relative to the directory tree given in the packing list. For example, the file bin/openuniverse was actually installed under /usr/X11R6, giving us /usr/X11R6/bin/openuniverse. Similarly, various files are listed as being in share/openuniverse, which is under /usr/X11R6, giving us the real directory of /usr/X11R6/share/openuniverse. Most files installed in a share directory are either documentation or program data. You can read the documentation, or just run openuniverse and see what happens. (Much of this information on files and directories is also available through pkg_info(1), but it’s frequently easier to just look for yourself.) 233
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services