796 lines
29 KiB
Text
796 lines
29 KiB
Text
<!-- $Id: ports.sgml,v 1.34 1998-12-12 07:08:16 asami Exp $ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
<chapt><heading>Installing Applications: The Ports collection<label id="ports"></heading>
|
|
|
|
<p><em>Contributed by &a.jraynard;.</em>
|
|
|
|
The FreeBSD Ports collection allows you to compile and install a very
|
|
wide range of applications with a minimum of effort.
|
|
|
|
<p> For all the hype about open standards, getting a program to work
|
|
on different versions of Unix in the real world can be a tedious and
|
|
tricky business, as anyone who has tried it will know. You may be lucky
|
|
enough to find that the program you want will compile cleanly on your
|
|
system, install itself in all the right places and run flawlessly
|
|
``out of the box'', but this is unfortunately rather rare. With most
|
|
programs, you will find yourself doing a fair bit of head-scratching,
|
|
and there are quite a few programs that will result in premature
|
|
greying, or even chronic alopecia...
|
|
|
|
<p> Some software distributions have attacked this problem by
|
|
providing configuration scripts. Some of these are very clever, but
|
|
they have an unfortunate tendency to triumphantly announce that your
|
|
system is something you have never heard of and then ask you lots of
|
|
questions that sound like a final exam in system-level Unix
|
|
programming (``Does your system's gethitlist function return a const
|
|
pointer to a fromboz or a pointer to a const fromboz? Do you have
|
|
Foonix style unacceptable exception handling? And if not, why not?'').
|
|
|
|
<p> Fortunately, with the Ports collection, all the hard work involved
|
|
has already been done, and you can just type 'make install' and get a
|
|
working program.
|
|
|
|
<sect><heading>Why Have a Ports Collection?</heading>
|
|
|
|
<p>The base FreeBSD system comes with a very wide range of tools and
|
|
system utilities, but a lot of popular programs are not in the base
|
|
system, for good reasons:-
|
|
|
|
<enum>
|
|
<item>Programs that some people cannot live without and other people
|
|
cannot stand, such as a certain Lisp-based editor.
|
|
|
|
<item>Programs which are too specialised to put in the base system
|
|
(CAD, databases).
|
|
|
|
<item>Programs which fall into the ``I must have a look at
|
|
that when I get a spare minute'' category, rather than system-critical
|
|
ones (some languages, perhaps).
|
|
|
|
<item>Programs that are far too much fun to be supplied with a serious
|
|
operating system like FreeBSD ;-)
|
|
|
|
<item>However many programs you put in the base system, people will
|
|
always want more, and a line has to be drawn somewhere (otherwise
|
|
FreeBSD distributions would become absolutely enormous).
|
|
</enum>
|
|
|
|
<p> Obviously it would be unreasonable to expect everyone to port their
|
|
favourite programs by hand (not to mention a tremendous amount of
|
|
duplicated work), so the FreeBSD Project came up with an ingenious
|
|
way of using standard tools that would automate the process.
|
|
|
|
<p> Incidentally, this is an excellent illustration of how ``the Unix way''
|
|
works in practice by combining a set of simple but very flexible tools
|
|
into something very powerful.
|
|
|
|
<sect><heading>How Does the Ports Collection Work?</heading>
|
|
<p>
|
|
Programs are typically distributed on the Internet as a
|
|
<ref id="ports:tarball" name="tarball"> consisting of
|
|
a Makefile and the source code for the program and usually
|
|
some instructions (which are unfortunately not always as instructive
|
|
as they could be), with perhaps a configuration script.
|
|
<p>
|
|
The standard scenario is that you FTP down the tarball, extract it
|
|
somewhere, glance through the instructions, make any changes that seem
|
|
necessary, run the configure script to set things up and use the standard
|
|
`make' program to compile and install the program from the source.
|
|
<p>
|
|
FreeBSD ports still use the tarball mechanism, but use a
|
|
<ref id="ports:skeleton" name="skeleton"> to hold the "knowledge"
|
|
of how to get the program working on FreeBSD, rather than expecting the
|
|
user to be able to work it out. They also supply their own customised
|
|
<ref id="ports:makefile" name="Makefile">, so that almost every port
|
|
can be built in the same way.
|
|
<p>
|
|
If you look at a port skeleton (either on <htmlurl
|
|
url="file://localhost/usr/ports/devel/ElectricFence" name="your FreeBSD
|
|
system"> or <htmlurl
|
|
url="ftp://ftp.freebsd.org/pub/FreeBSD/ports/devel/ElectricFence" name="the
|
|
FTP site">) and expect to find all sorts of pointy-headed rocket
|
|
science lurking there, you may be disappointed by the one or two
|
|
rather unexciting-looking files and directories you find there.
|
|
(We will discuss in a minute how to go about <ref id="ports:getting"
|
|
name="Getting a port">).
|
|
|
|
<p>``How on earth can this do anything?'' I hear you cry. ``There
|
|
is no source code there!''
|
|
|
|
<p> Fear not, gentle reader, all will become clear (hopefully). Let's
|
|
see what happens if we try and install a port. I have chosen `ElectricFence',
|
|
a useful tool for developers, as the skeleton is more straightforward than
|
|
most.
|
|
|
|
<em>Note</em> if you are trying this at home, you will need to be root.
|
|
|
|
<verb>
|
|
# cd /usr/ports/devel/ElectricFence
|
|
# make install
|
|
>> Checksum OK for ElectricFence-2.0.5.tar.gz.
|
|
===> Extracting for ElectricFence-2.0.5
|
|
===> Patching for ElectricFence-2.0.5
|
|
===> Applying FreeBSD patches for ElectricFence-2.0.5
|
|
===> Configuring for ElectricFence-2.0.5
|
|
===> Building for ElectricFence-2.0.5
|
|
[lots of compiler output...]
|
|
===> Installing for ElectricFence-2.0.5
|
|
===> Warning: your umask is "0002".
|
|
If this is not desired, set it to an appropriate value
|
|
and install this port again by ``make reinstall''.
|
|
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib
|
|
install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3
|
|
===> Compressing manual pages for ElectricFence-2.0.5
|
|
===> Registering installation for ElectricFence-2.0.5
|
|
</verb>
|
|
|
|
<p> To avoid confusing the issue, I have completely removed the build output.
|
|
<p>If you tried this yourself, you may well have got something like this at
|
|
the start:-
|
|
|
|
<label id="ports:fetch">
|
|
<verb>
|
|
# make install
|
|
>> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system.
|
|
>> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/.
|
|
</verb>
|
|
|
|
<p> The `make' program has noticed that you did not have a local copy
|
|
of the source code and tried to FTP it down so it could get the job
|
|
done. I already had the
|
|
source handy in my example, so it did not need to fetch it.
|
|
|
|
<p> Let's go through this and see what the `make' program was doing.
|
|
|
|
<enum>
|
|
<item> Locate the source code <ref id="ports:tarball"
|
|
name="tarball."> If it is not available locally, try to grab it from an
|
|
FTP site.
|
|
|
|
<item> Run a <ref id="ports:checksum" name="checksum"> test on the
|
|
tarball to make sure it has not been tampered with, accidentally
|
|
truncated, downloaded in ASCII mode, struck by neutrinos while in transit, etc.
|
|
|
|
<item> Extract the tarball into a temporary work directory.
|
|
|
|
<item> Apply any <ref id="ports:patch" name="patches"> needed to get
|
|
the source to compile and run under FreeBSD.
|
|
|
|
<item> Run any configuration script required by the build process and
|
|
correctly answer any questions it asks.
|
|
|
|
<item> (Finally!) Compile the code.
|
|
|
|
<item> Install the program executable and other supporting files, man
|
|
pages, etc. under the /usr/local hierarchy, where they will not get mixed
|
|
up with system programs. This also makes sure that all the ports you
|
|
install will go in the same place, instead of being flung all over
|
|
your system.
|
|
|
|
<item> Register the installation in a database. This means
|
|
that, if you do not like the program, you can cleanly <ref
|
|
id="ports:remove" name="remove"> all traces of it from your system.
|
|
|
|
</enum>
|
|
|
|
<p> Scroll up to the make output and see if you can match these steps to it.
|
|
And if you were not impressed before, you should be by now!
|
|
|
|
<sect><heading>Getting a FreeBSD Port<label id="ports:getting"></heading>
|
|
<p>
|
|
There are two ways of getting hold of the FreeBSD port for a
|
|
program. One requires a <ref id="ports:cd" name="FreeBSD
|
|
CDROM">, the other involves using an <ref id="ports:inet"
|
|
name="Internet Connection.">
|
|
|
|
<sect1><heading>Compiling ports from CDROM<label id="ports:cd"></heading>
|
|
<p>
|
|
Assuming that your <em /FreeBSD/ CDROM is in the drive and mounted on
|
|
/cdrom (and the mount point *must* be /cdrom), you should then be able
|
|
to build ports just as you normally do and the port collection's built
|
|
in search path should find the tarballs in file:/cdrom/ports/distfiles/
|
|
(if they exist there) rather than downloading them over the net.
|
|
|
|
<p>
|
|
Another way of doing this, if you want to just use the port skeletons
|
|
on the CDROM, is to set these variables in <tt>/etc/make.conf</tt>:
|
|
<tscreen><verb>
|
|
PORTSDIR= /cdrom/ports
|
|
DISTDIR= /tmp/distfiles
|
|
WRKDIRPREFIX= /tmp
|
|
</verb></tscreen>
|
|
(substitute "/tmp" for any place you have enough free space). Then,
|
|
just cd to the appropriate subdirectory under "/cdrom/ports" and type
|
|
"make install" as usual. <tt/WRKDIRPREFIX/ will cause the port to be
|
|
built under /tmp/cdrom/ports; for instance, games/oneko will be built
|
|
under /tmp/cdrom/ports/games/oneko.
|
|
|
|
<p>
|
|
Note that there are some ports for which we cannot provide the original
|
|
source in the CDROM due to licensing limitations. In that case,
|
|
you will need to look at the section on <ref id="ports:inet"
|
|
name="Compiling ports using an Internet connection.">
|
|
|
|
<sect1><heading>Compiling ports from the Internet<label
|
|
id="ports:inet"></heading>
|
|
<p>
|
|
If you do not have a CDROM, or you want to make sure you get the very
|
|
latest version of the port you want, you will need to download the
|
|
<ref id="ports:skeleton" name="skeleton"> for the port. Now this
|
|
might sound like rather a fiddly job
|
|
full of pitfalls, but it is actually very easy.
|
|
<p>
|
|
First, if you are running a release version of FreeBSD, make sure you
|
|
get the appropriate ``upgrade kit'' for your release from the <htmlurl
|
|
url="http://www.freebsd.org/ports/" name="ports page">. These
|
|
packages include files that have been updated since the release that
|
|
you may need to compile new ports.
|
|
<p>
|
|
The key to the skeletons is that the FreeBSD FTP server can create on-the-fly
|
|
<ref id="ports:tarball" name="tarballs"> for you. Here is how it works,
|
|
with the gnats program in the databases directory as an example (the
|
|
bits in square brackets are comments. Do not type them in if you are
|
|
trying this yourself!):-
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# mkdir databases
|
|
# cd databases
|
|
# ftp ftp.freebsd.org
|
|
[log in as `ftp' and give your email address when asked for a
|
|
password. Remember to use binary (also known as image) mode!]
|
|
> cd /pub/FreeBSD/ports/databases
|
|
> get gnats.tar [tars up the gnats skeleton for us]
|
|
> quit
|
|
# tar xf gnats.tar [extract the gnats skeleton]
|
|
# cd gnats
|
|
# make install [build and install gnats]
|
|
</verb>
|
|
|
|
What happened here? We connected to the FTP server in the usual way
|
|
and went to its databases sub-directory. When we gave it the command
|
|
`get gnats.tar', the FTP server <ref id="ports:tarball"
|
|
name="tarred"> up the gnats directory for us.
|
|
<p>
|
|
We then extracted the gnats skeleton and went into the gnats directory
|
|
to build the port. As we explained <ref id="ports:fetch"
|
|
name="earlier">, the make process noticed we did not have a copy of the
|
|
source locally, so it fetched one before extracting, patching and
|
|
building it.
|
|
<p>
|
|
Let's try something more ambitious now. Instead of getting a single
|
|
port skeleton, let's get a whole sub-directory, for example all the
|
|
database skeletons in the ports collection. It looks almost the same:-
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# ftp ftp.freebsd.org
|
|
[log in as `ftp' and give your email address when asked for a
|
|
password. Remember to use binary (also known as image) mode!]
|
|
> cd /pub/FreeBSD/ports
|
|
> get databases.tar [tars up the databases directory for us]
|
|
> quit
|
|
# tar xf databases.tar [extract all the database skeletons]
|
|
# cd databases
|
|
# make install [build and install all the database ports]
|
|
</verb>
|
|
|
|
With half a dozen straightforward commands, we have now got a set of
|
|
database programs on our FreeBSD machine! All we did that was
|
|
different from getting a single port skeleton and building it was that
|
|
we got a whole directory at once, and compiled everything in it at
|
|
once. Pretty impressive, no?
|
|
<p>
|
|
If you expect to be installing many ports, it is
|
|
probably worth downloading all the ports directories.
|
|
|
|
<sect><heading>Skeletons<label id="ports:skeleton"></heading>
|
|
<p>
|
|
A team of compulsive hackers who have forgotten to eat in a frantic
|
|
attempt to make a deadline? Something unpleasant lurking in the FreeBSD
|
|
attic? No, a skeleton here is a minimal framework that supplies everything
|
|
needed to make the ports magic work.
|
|
|
|
<sect1><heading>Makefile<label id="ports:makefile"></heading>
|
|
<p>
|
|
The most important component of a skeleton is the Makefile. This contains
|
|
various statements that specify how the port should be compiled and
|
|
installed. Here is the Makefile for ElectricFence:-
|
|
|
|
<verb>
|
|
# New ports collection makefile for: Electric Fence
|
|
# Version required: 2.0.5
|
|
# Date created: 13 November 1997
|
|
# Whom: jraynard
|
|
#
|
|
# $Id: ports.sgml,v 1.34 1998-12-12 07:08:16 asami Exp $
|
|
#
|
|
|
|
DISTNAME= ElectricFence-2.0.5
|
|
CATEGORIES= devel
|
|
MASTER_SITES= ${MASTER_SITE_SUNSITE}
|
|
MASTER_SITE_SUBDIR= devel/lang/c
|
|
|
|
MAINTAINER= jraynard@freebsd.org
|
|
|
|
MAN3= libefence.3
|
|
|
|
do-install:
|
|
${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib
|
|
${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3
|
|
|
|
.include <bsd.port.mk>
|
|
</verb>
|
|
|
|
The lines beginning with a "#" sign are comments for the benefit
|
|
of human readers (as in most Unix script files).
|
|
<p>
|
|
`DISTNAME" specifies the name of the <ref id="ports:tarball"
|
|
name="tarball">, but without the extension.
|
|
<p>
|
|
`CATEGORIES" states what kind of program this is. In this case, a
|
|
utility for developers. See the <ref id="porting:categories"
|
|
name="categories"> section of this handbook for a complete list.
|
|
<p>
|
|
`MASTER_SITES" is the URL(s) of the master FTP site, which is
|
|
used to retrieve the <ref id="ports:tarball" name="tarball"> if it is not
|
|
available on the local system. This is a site which is regarded as
|
|
reputable, and is normally the one from which the program is officially
|
|
distributed (in so far as any software is "officially" distributed
|
|
on the Internet).
|
|
<p>
|
|
`MAINTAINER" is the email address of the person who is
|
|
responsible for updating the skeleton if, for example a new version
|
|
of the program comes out.
|
|
<p>
|
|
Skipping over the next few lines for a minute, the line
|
|
<verb>
|
|
.include <bsd.port.mk>
|
|
</verb>
|
|
says that the other statements and commands
|
|
needed for this port are in a standard file called
|
|
`bsd.port.mk". As these are the same for all ports, there is
|
|
no point in duplicating them all over the place, so they are kept in a
|
|
single standard file.
|
|
<p>
|
|
This is probably not the place to go into a detailed examination of
|
|
how Makefiles work; suffice it to say that the line starting with ``MAN3''
|
|
ensures that the ElectricFence man page is compressed after installation,
|
|
to help conserve your precious disk space. The original port did not
|
|
provide an ``install'' target, so the three lines from ``do-install''
|
|
ensure that the files produced by this port are placed in the correct
|
|
destination.
|
|
|
|
<sect1><heading>The files directory</heading>
|
|
<p>
|
|
The file containing the <ref id="ports:checksum" name="checksum"> for
|
|
the port is called "md5", after the MD5 algorithm
|
|
used for ports checksums. It lives in a directory with the slightly
|
|
confusing name of "files".
|
|
<p>
|
|
This directory can also contain other miscellaneous files that are required
|
|
by the port and do not belong anywhere else.
|
|
|
|
<sect1><heading>The patches directory</heading>
|
|
<p>
|
|
This directory contains the <ref id="ports:patch" name="patches"> needed
|
|
to make everything work properly under FreeBSD.
|
|
|
|
<sect1><heading>The pkg directory</heading>
|
|
<p>
|
|
This program contains three quite useful files:-
|
|
|
|
<itemize>
|
|
<item>
|
|
COMMENT - a one-line description of the program.
|
|
|
|
<item>
|
|
DESCR - a more detailed description.
|
|
|
|
<item>
|
|
PLIST - a list of all the files that will be created when the program is installed.
|
|
</itemize>
|
|
|
|
<sect><heading>What to do when a port does not work.<label id="ports:troubleshooting"></heading>
|
|
|
|
<p>Oh. You can do one of four (4) things :
|
|
|
|
<enum>
|
|
<item> Fix it yourself. Technical details on how ports work can be found in
|
|
<ref id="porting" name="Porting applications.">
|
|
<item> Gripe. This is done by e-mail *ONLY*! Send such e-mail to the &a.ports;
|
|
and please include the name/version of the port, where you got both the port
|
|
source & distfile(s) from, and what the text of the error was.
|
|
|
|
<item> Forget it. This is the easiest for most - very few of the programs in
|
|
ports can be classified as `essential'!
|
|
|
|
<item> Grab the pre-compiled package from a ftp server. The ``master'' package
|
|
collection is on FreeBSD's FTP server in the <htmlurl
|
|
url="ftp://ftp.FreeBSD.org/pub/FreeBSD/packages/"
|
|
name="packages directory">, though check your local mirror first, please!
|
|
|
|
These are more likely to work (on the whole) than trying to compile from
|
|
source and a lot faster besides! Use the <tt>pkg_add(1)</tt>
|
|
program to install a package file on your system.
|
|
|
|
</enum>
|
|
|
|
<sect><heading>Some Questions and Answers</heading>
|
|
<p>
|
|
<itemize>
|
|
<item>
|
|
Q. I thought this was going to be a discussion about modems??!
|
|
<p>
|
|
A. Ah. You must be thinking of the serial ports on the back of your
|
|
computer. We are using `port' here to mean the result of `porting' a
|
|
program from one version of Unix to another. (It is an unfortunate bad
|
|
habit of computer people to use the same word to refer to several
|
|
completely different things).
|
|
|
|
<item>
|
|
Q. I thought you were supposed to use packages to install extra
|
|
programs?
|
|
<p>
|
|
A. Yes, that is usually the quickest and easiest way of doing it.
|
|
|
|
<item>
|
|
Q. So why bother with ports then?
|
|
<p>
|
|
A. Several reasons:-
|
|
|
|
<enum>
|
|
<item> The licensing conditions on some software distributions
|
|
require that they be distributed as source code, not binaries.
|
|
|
|
<item> Some people do not trust binary distributions. At least with
|
|
source code you can (in theory) read through it and look for potential
|
|
problems yourself.
|
|
|
|
<item> If you have some local patches, you will need the source to add
|
|
them yourself.
|
|
|
|
<item> You might have opinions on how a program should be compiled
|
|
that differ from the person who did the package - some people have
|
|
strong views on what optimisation setting should be used, whether to
|
|
build debug versions and then strip them or not, etc. etc.
|
|
|
|
<item> Some people like having code around, so they can read it if
|
|
they get bored, hack around with it, borrow from it (licence terms
|
|
permitting, of course!) and so on.
|
|
|
|
<item> If you ain't got the source, it ain't software! ;-)
|
|
</enum>
|
|
|
|
<item><label id="ports:patch">
|
|
Q. What is a patch?
|
|
<p>
|
|
A. A patch is a small (usually) file that specifies how to go from one
|
|
version of a file to another. It contains text that says, in effect,
|
|
things like ``delete line 23'', ``add these two lines after line 468''
|
|
or ``change line 197 to this''. Also known as a `diff', since it is
|
|
generated by a program of that name.
|
|
|
|
<item><label id="ports:tarball">
|
|
Q. What is all this about tarballs?
|
|
<p>
|
|
A. It is a file ending in .tar or .tar.gz (with variations like .tar.Z, or
|
|
even .tgz if you are trying to squeeze the names into a DOS filesystem).
|
|
<p>
|
|
Basically, it is a directory tree that has been archived into a single
|
|
file (.tar) and optionally compressed (.gz). This technique was originally
|
|
used for <em /T/ape <em /AR/chives (hence the name `tar'), but it is a
|
|
widely used way of distributing program source code around the
|
|
Internet.
|
|
<p>
|
|
You can see what files are in them, or even extract them yourself, by
|
|
using the standard Unix tar program, which comes with the base FreeBSD
|
|
system, like this:-
|
|
|
|
<verb>
|
|
tar tvzf foobar.tar.gz # View contents of foobar.tar.gz
|
|
tar xzvf foobar.tar.gz # Extract contents into the current directory
|
|
tar tvf foobar.tar # View contents of foobar.tar
|
|
tar xvf foobar.tar # Extract contents into the current directory
|
|
</verb>
|
|
|
|
<item><label id="ports:checksum">
|
|
Q. And a checksum?
|
|
<p>
|
|
A. It is a number generated by adding up all the data in the file you
|
|
want to check. If any of the characters change, the checksum will no
|
|
longer be equal to the total, so a simple comparison will allow you to
|
|
spot the difference. (In practice, it is done in a more complicated way
|
|
to spot problems like position-swapping, which will not show up with a
|
|
simplistic addition).
|
|
|
|
<item>
|
|
Q. I did what you said for <ref id="ports:cd" name="compiling ports
|
|
from a CDROM"> and it worked great until I tried to install the kermit
|
|
port:-
|
|
|
|
<verb>
|
|
# make install
|
|
>> cku190.tar.gz doesn't seem to exist on this system.
|
|
>> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.
|
|
</verb>
|
|
|
|
Why can it not be found? Have I got a dud CDROM?
|
|
<p>
|
|
A. The licensing terms for kermit do not allow us to put the tarball
|
|
for it on the CDROM, so you will have to fetch it by hand - sorry!
|
|
The reason why you got all those error messages was because you
|
|
were not connected to the Internet at the time. Once you have downloaded
|
|
it from any of the sites above, you can re-start the process (try and
|
|
choose the nearest site to you, though, to save your time and the
|
|
Internet's bandwidth).
|
|
|
|
<item>
|
|
Q. I did that, but when I tried to put it into /usr/ports/distfiles I
|
|
got some error about not having permission.
|
|
<p>
|
|
A. The ports mechanism looks for the tarball in /usr/ports/distfiles,
|
|
but you will not be able to copy anything there because it is sym-linked
|
|
to the CDROM, which is read-only. You can tell it to look somewhere
|
|
else by doing
|
|
|
|
<verb>
|
|
DISTDIR=/where/you/put/it make install
|
|
</verb>
|
|
|
|
<item>
|
|
Q. Does the ports scheme only work if you have everything in
|
|
/usr/ports? My system administrator says I must put everything under
|
|
/u/people/guests/wurzburger, but it does not seem to work.
|
|
<p>
|
|
A. You can use the PORTSDIR and PREFIX variables to tell the ports
|
|
mechanism to use different directories. For instance,
|
|
|
|
<verb>
|
|
make PORTSDIR=/u/people/guests/wurzburger/ports install
|
|
</verb>
|
|
|
|
will compile the port in /u/people/guests/wurzburger/ports and install
|
|
everything under /usr/local.
|
|
|
|
<verb>
|
|
make PREFIX=/u/people/guests/wurzburger/local install
|
|
</verb>
|
|
|
|
will compile it in /usr/ports and install it in
|
|
/u/people/guests/wurzburger/local.
|
|
|
|
And of course
|
|
|
|
<verb>
|
|
make PORTSDIR=.../ports PREFIX=.../local install
|
|
</verb>
|
|
|
|
will combine the two (it is too long to fit on the page if I write it
|
|
in full, but I am sure you get the idea).
|
|
<p>
|
|
If you do not fancy typing all that in every time you install a port
|
|
(and to be honest, who would?), it is a good idea to put these variables
|
|
into your environment.
|
|
|
|
<item>
|
|
Q. I do not have a FreeBSD CDROM, but I would like to have all the tarballs
|
|
handy on my system so I do not have to wait for a download every time I
|
|
install a port. Is there an easy way to get them all at once?
|
|
<p>
|
|
A. To get every single tarball for the ports collection, do
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# make fetch
|
|
</verb>
|
|
|
|
For all the tarballs for a single ports directory, do
|
|
|
|
<verb>
|
|
# cd /usr/ports/directory
|
|
# make fetch
|
|
</verb>
|
|
|
|
and for just one port - well, I think you have guessed already.
|
|
|
|
<item>
|
|
Q. I know it is probably faster to fetch the tarballs from one of the
|
|
FreeBSD mirror sites close by. Is there any way to tell the port to
|
|
fetch them from servers other than ones listed in the MASTER_SITES?
|
|
<p>
|
|
A. Yes. If you know, for example, ftp.FreeBSD.ORG is much closer than
|
|
sites listed in MASTER_SITES, do as following example.
|
|
<verb>
|
|
# cd /usr/ports/directory
|
|
# make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/distfiles/ fetch
|
|
</verb>
|
|
|
|
<item>
|
|
Q. I want to know what files make is going to need before it tries to
|
|
pull them down.
|
|
<p>
|
|
A. 'make fetch-list' will display a list of the files needed for a port.
|
|
|
|
<item>
|
|
Q. Is there any way to stop the port from compiling? I want to do some
|
|
hacking on the source before I install it, but it is a bit tiresome having
|
|
to watch it and hit control-C every time.
|
|
<p>
|
|
A. Doing 'make extract' will stop it after it has fetched and
|
|
extracted the source code.
|
|
|
|
<item>
|
|
Q. I am trying to make my own port and I want to be able to stop it
|
|
compiling until I have had a chance to see if my patches worked properly.
|
|
Is there something like 'make extract', but for patches?
|
|
<p>
|
|
A. Yep, 'make patch' is what you want. You will probably find the
|
|
PATCH_DEBUG option useful as well. And by the way, thank you for
|
|
your efforts!
|
|
|
|
<item>
|
|
Q. I have heard that some compiler options can cause bugs. Is this true?
|
|
How can I make sure that I compile ports with the right settings?
|
|
<p>
|
|
A. Yes, with version 2.6.3 of gcc (the version shipped with FreeBSD
|
|
2.1.0 and 2.1.5), the -O2 option could result in buggy code unless you
|
|
used the -fno-strength-reduce option as well. (Most of the ports don't
|
|
use -O2). You <em /should/ be able to specify the compiler options
|
|
used by something like
|
|
|
|
<verb>
|
|
make CFLAGS='-O2 -fno-strength-reduce' install
|
|
</verb>
|
|
|
|
or by editing /etc/make.conf, but unfortunately not all ports respect
|
|
this. The surest way is to do 'make configure', then go into the
|
|
source directory and inspect the Makefiles by hand, but this can get
|
|
tedious if the source has lots of sub-directories, each with their own
|
|
Makefiles.
|
|
|
|
<item>
|
|
Q. There are so many ports it is hard to find the one I want. Is there a
|
|
list anywhere of what ports are available?
|
|
<p>
|
|
A. Look in the INDEX file in /usr/ports. If you would like to search
|
|
the ports collection for a keyword, you can do that too. For example,
|
|
you can find ports relevant to the LISP programming language using:
|
|
|
|
<verb>
|
|
cd /usr/ports
|
|
make search key=lisp
|
|
</verb>
|
|
|
|
<item>
|
|
Q. I went to install the 'foo' port but the system suddenly stopped
|
|
compiling it and starting compiling the 'bar' port. What's going on?
|
|
<p>
|
|
A. The 'foo' port needs something that is supplied with 'bar' - for
|
|
instance, if 'foo' uses graphics, 'bar' might have a library with
|
|
useful graphics processing routines. Or 'bar' might be a tool that is
|
|
needed to compile the 'foo' port.
|
|
|
|
<item><label id="ports:remove">
|
|
Q. I installed the grizzle program from the ports and frankly it is a
|
|
complete waste of disk space. I want to delete it but I do not know
|
|
where it put all the files. Any clues?
|
|
<p>
|
|
A. No problem, just do
|
|
|
|
<verb>
|
|
pkg_delete grizzle-6.5
|
|
</verb>
|
|
<item>
|
|
|
|
Q. Hang on a minute, you have to know the version number to use that
|
|
command. You do not seriously expect me to remember that, do you??
|
|
<p>
|
|
A. Not at all, you can find it out by doing
|
|
|
|
<verb>
|
|
pkg_info -a | grep grizzle
|
|
</verb>
|
|
|
|
And it will tell you:-
|
|
|
|
<verb>
|
|
Information for grizzle-6.5:
|
|
grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game.
|
|
</verb>
|
|
|
|
<item>
|
|
Q. Talking of disk space, the ports directory seems to be taking up
|
|
an awful lot of room. Is it safe to go in there and delete things?
|
|
<p>
|
|
A. Yes, if you have installed the program and are fairly certain you
|
|
will not need the source again, there is no point in keeping it hanging
|
|
around. The best way to do this is
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# make clean
|
|
</verb>
|
|
|
|
which will go through all the ports subdirectories and delete
|
|
everything except the skeletons for each port.
|
|
<item>
|
|
Q. I tried that and it still left all those tarballs or whatever you
|
|
called them in the distfiles directory. Can I delete those as well?
|
|
<p>
|
|
A. Yes, if you are sure you have finished with them, those can go as
|
|
well.
|
|
|
|
<item>
|
|
Q. I like having lots and lots of programs to play with. Is there any
|
|
way of installing all the ports in one go?
|
|
<p>
|
|
A. Just do
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# make install
|
|
</verb>
|
|
|
|
<item>
|
|
Q. OK, I tried that, but I thought it would take a very long time so I
|
|
went to bed and left it to get on with it. When I looked at the
|
|
computer this morning, it had only done three and a half ports. Did
|
|
something go wrong?
|
|
<p>
|
|
A. No, the problem is that some of the ports need to ask you questions
|
|
that we cannot answer for you (eg ``Do you want to print on A4 or US
|
|
letter sized paper?'') and they need to have someone on hand to answer
|
|
them.
|
|
|
|
<item>
|
|
Q. I really do not want to spend all day staring at the monitor. Any
|
|
better ideas?
|
|
<p>
|
|
A. OK, do this before you go to bed/work/the local park:-
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# make -DBATCH install
|
|
</verb>
|
|
|
|
This will install every port that does <em /not/ require user
|
|
input. Then, when you come back, do
|
|
|
|
<verb>
|
|
# cd /usr/ports
|
|
# make -DIS_INTERACTIVE install
|
|
</verb>
|
|
|
|
to finish the job.
|
|
|
|
<item>
|
|
Q. At work, we are using frobble, which is in your ports collection,
|
|
but we have altered it quite a bit to get it to do what we need. Is
|
|
there any way of making our own packages, so we can distribute it more
|
|
easily around our sites?
|
|
<p>
|
|
A. No problem, assuming you know how to make patches for your changes:-
|
|
|
|
<verb>
|
|
# cd /usr/ports/somewhere/frobble
|
|
# make extract
|
|
# cd work/frobble-2.8
|
|
[Apply your patches]
|
|
# cd ../..
|
|
# make package
|
|
</verb>
|
|
|
|
<item>
|
|
Q. This ports stuff is really clever. I am desperate to find out how
|
|
you did it. What is the secret?
|
|
<p>
|
|
A. Nothing secret about it at all, just look at the bsd.ports.mk and
|
|
bsd.ports.subdir.mk files in your <htmlurl
|
|
url="file://localhost/usr/share/mk/" name="makefiles directory.">
|
|
(Note: readers with an aversion to intricate shell-scripts are advised
|
|
not to follow this link...)
|
|
</itemize>
|
|
|
|
&porting;
|