1540 lines
61 KiB
Text
1540 lines
61 KiB
Text
# $NetBSD: Packages.txt,v 1.43 1998/08/24 10:31:00 agc Exp $
|
|
###########################################################################
|
|
|
|
==========================
|
|
Documentation on the
|
|
NetBSD Package System
|
|
==========================
|
|
|
|
Hubert Feyrer, Alistair Crooks
|
|
|
|
|
|
Table of contents:
|
|
==================
|
|
|
|
grep -B1 '^.====' Packages.txt | egrep -v '^.[-=]'
|
|
|
|
|
|
0 Intro
|
|
========
|
|
|
|
There is a lot of software freely available for Unix based systems, which
|
|
usually runs on NetBSD, too, sometimes with some modifications. The NetBSD
|
|
packages collection incorporates any such changes necessary to make that
|
|
software run on NetBSD, and makes the installation (and reinstallation) of
|
|
the software package easy by means of a single command.
|
|
|
|
The NetBSD package system is used to enable such freely available
|
|
third-party software to be built easily on NetBSD hosts. Once the software
|
|
has been built, it is manipulated with the pkg_* tools so that installation
|
|
and de-installation, printing of an inventory of all installed packages and
|
|
retrieval of one-line comments or more verbose descriptions are all simple.
|
|
|
|
Both the NetBSD packages collection and the NetBSD package system are
|
|
derived from FreeBSD.
|
|
|
|
|
|
0.1 Overview
|
|
=============
|
|
|
|
This document is divided into two parts. The first, "User's Guide",
|
|
describes how one can use one of the packages in the Package
|
|
Collection, either by installing a precompiled binary package, or by
|
|
building your own copy using the NetBSD package system. The second
|
|
part, "Package Constructor's Guide", explains how to prepare a package so
|
|
it can be easily built by other NetBSD users without knowing about the
|
|
package's building details.
|
|
|
|
|
|
0.2 Terminology
|
|
===============
|
|
|
|
There has been a lot of talk about "ports", "packages", etc. so far. Here
|
|
is a description of all the terminology used within this document:
|
|
|
|
* Package:
|
|
A set of files and building instructions that describe what's necessary
|
|
to build a certain piece of software using the NetBSD package
|
|
system. Packages are traditionally stored under /usr/pkgsrc.
|
|
|
|
* The NetBSD package system:
|
|
This is the part of the NetBSD operating system handling building
|
|
(compiling), installing and removing of packages.
|
|
|
|
* Distfile:
|
|
This term describes the file or files that are provided by the author
|
|
of the piece of freely available software to distribute his work. All
|
|
the changes necessary to build on NetBSD are reflected in the
|
|
corresponding package. Usually the distfile is in the form of a
|
|
compressed tar-archive, but other types are possible, too. Distfiles
|
|
are stored below /usr/pkgsrc/distfiles.
|
|
|
|
* Port:
|
|
This is the term used by FreeBSD people for what we call a package.
|
|
In NetBSD terminology, "port" refers to a different architecture.
|
|
|
|
* Precompiled (binary) package:
|
|
A set of binaries built by the NetBSD package system from a distfile
|
|
using the NetBSD package system and stuffed together in a single .tgz
|
|
file so it can be installed on machines of the same machine architecture
|
|
without the need to recompile. Packages are generated in
|
|
/usr/pkgsrc/packages by the NetBSD package system; there is also an
|
|
archive on ftp.netbsd.org.
|
|
|
|
Sometimes, this is referred to by the term "package" too, esp. in the
|
|
context of precompiled packages.
|
|
|
|
* Program:
|
|
The piece of software to be installed which will be constructed from
|
|
all the files in the Distfile by the actions defined in the
|
|
corresponding package.
|
|
|
|
* RCS IDs:
|
|
Some files in a package contain RCS IDs to reflect which version of
|
|
that file this is (inserted automatically by cvs). These IDs are used
|
|
in several examples within this document, but as this document itself
|
|
is managed by CVS, it can't list the RCS IDs in plaintext. Instead, the
|
|
$s are written as <$>, resulting in <$>NetBSD<$> and <$>Id<$>.
|
|
|
|
|
|
====================
|
|
Part I: User's Guide
|
|
====================
|
|
|
|
1 Installing a precompiled binary package
|
|
=========================================
|
|
|
|
This section describes how to find, retrieve and install a precompiled
|
|
binary package that someone else already prepared for your type of machine.
|
|
|
|
|
|
1.1 Where to get
|
|
================
|
|
|
|
Precompiled packages are stored on ftp.netbsd.org and its mirrors in the
|
|
directory /pub/NetBSD/packages for anon FTP access. Please pick the right
|
|
subdirectory there as indicated by "sysctl hw.machine_arch". In that
|
|
directory, there is a subdirectory for each category plus a subdirectory
|
|
"All" which includes the actual binaries in .tgz-files. The category
|
|
subdirectories use symbolic links to those files. (This is the same
|
|
directory layout as in /usr/pkgsrc/packages).
|
|
|
|
This same directory layout applies for CDROM distributions, only that the
|
|
directory may be rooted somewhere else, probably somewhere below /cdrom.
|
|
Please consult your CDROM's documentation for the exact location!
|
|
|
|
|
|
1.2 How to do
|
|
=============
|
|
|
|
If you have the files on a CDROM or downloaded them to your hard disk, you
|
|
can install them with the following command (be sure to su to root first):
|
|
|
|
pkg_add /path/to/package.tgz
|
|
|
|
If you have FTP access and you don't want to download the packages via FTP
|
|
prior to installation, you can do this automatically by giving pkg_add an
|
|
ftp-URL:
|
|
|
|
pkg_add ftp://ftp.netbsd.org/pub/packages/`sysctl -n hw.machine_arch`/All/package.tgz
|
|
|
|
Please note that sysctl is used here to automatically determine the right
|
|
set of binary files. Also note that any packages needed to run the package
|
|
in question will be installed, too, assuming they are present where you
|
|
install from.
|
|
|
|
After you've installed packages, be sure to have /usr/pkg in your $PATH so
|
|
you can actually start the just installed program.
|
|
|
|
|
|
1.3 A word of warning
|
|
=====================
|
|
|
|
Please pay very careful attention to the warnings expressed in that manual
|
|
page about the inherent dangers of installing binary packages which you did
|
|
not create yourself, and the security holes that can be introduced onto
|
|
your system by indiscriminate adding of such files.
|
|
|
|
|
|
2 Installing by Building
|
|
========================
|
|
|
|
This assumes that the package is already part of the NetBSD package system.
|
|
If it is not, then you are advised to read part II of this document,
|
|
"Package Constructor's Guide".
|
|
|
|
|
|
2.1 Where to get pkgsrc
|
|
=======================
|
|
|
|
To get the package source going, you need to get the pkgsrc.tar.gz file
|
|
from ftp://ftp.netbsd.org/pub/NetBSD-current/tar_files/pkgsrc.tar.gz and
|
|
unpack it into /usr/pkgsrc.
|
|
|
|
As an alternative, you can get pkgsrc via the Software Update Protocol,
|
|
SUP. To do so, make sure your supfile has a line saying "release=pkgsrc" in
|
|
it, see the examples in /usr/share/examples/supfiles, and that the
|
|
directory /usr/pkgsrc does exist. Then, simply start "sup -v
|
|
/path/to/your/supfile".
|
|
|
|
|
|
2.2 Fetching distfiles
|
|
======================
|
|
|
|
There is one gotcha: The distribution file (i.e. the unmodified source)
|
|
must exist on your system for the packages system to be able to build it.
|
|
If it's not, then ftp(1) is used to fetch the distribution files
|
|
automatically.
|
|
|
|
If you don't have a permanent Internet connection and you want to know
|
|
which files to download, "make fetch-list" will tell you what you'll need.
|
|
Put these distfiles into /usr/pkgsrc/distfiles.
|
|
|
|
|
|
2.3 How to build and install
|
|
============================
|
|
|
|
Assuming that has been done, become root and change into the relevant
|
|
directory. Then you can type
|
|
|
|
make
|
|
|
|
at the shell prompt to build the various components of the package, and
|
|
|
|
make install
|
|
|
|
at the shell prompt to install the various components into the correct
|
|
places on your system.
|
|
|
|
Taking the top system utility as an example, we can install it on our
|
|
system by building as shown in A.1.
|
|
|
|
The program is installed under the default root of the packages tree -
|
|
/usr/pkg. Should this not conform to your tastes, simply set the LOCALBASE
|
|
variable in your environment, and it will use that value as the root of
|
|
your packages tree. So, to use /usr/local, set
|
|
|
|
LOCALBASE=/usr/local
|
|
|
|
in your environment. There is, of course, one exception to this - X11
|
|
packages are traditionally installed in the X11 tree. The environment
|
|
variable which governs an X11 package's location is X11BASE. So to
|
|
install an X11 package into /usr/local/X11R6, set
|
|
|
|
X11BASE=/usr/local/X11R6
|
|
|
|
in your environment.
|
|
|
|
However, beware that strange things may happen if you install X11
|
|
packages outside the X11 tree, in that libraries and header files may
|
|
not be found by other software, and Application Defaults may not be
|
|
found. For that reason, you are advised to leave X11 packages in the
|
|
X11 tree. We are looking at ways to change this.
|
|
|
|
|
|
3 Making a precompiled package
|
|
==============================
|
|
|
|
Once you have built and installed the package as mentioned above, you can
|
|
build it into a "binary package" - you might want to do this so that you
|
|
can use the binaries you have just built on another NetBSD system, or to
|
|
provide a simple means for others to use your binary package instead of
|
|
wasting CPU time - this is done by changing to the appropriate directory in
|
|
the pkgsrc tree, and typing the command
|
|
|
|
make package
|
|
|
|
at the shell prompt. This will build and install your package (if not
|
|
already done), and then construct a binary package out of the results so
|
|
that you can use the pkg_* tools to manipulate this. The binary package is
|
|
stored under /usr/pkgsrc/packages, it's in the form of a gzipped file at
|
|
the present time. See appendix A.2 for a continuation of the above top
|
|
example.
|
|
|
|
Please see the "submitting" section later in this document on how to submit
|
|
such a binary package.
|
|
|
|
|
|
====================================
|
|
Part II: Package Constructor's Guide
|
|
====================================
|
|
|
|
4 Package components - files, directories and contents
|
|
======================================================
|
|
|
|
Whenever you're preparing a package from the FreeBSD ports collection or
|
|
doing it from scratch, there is a number of files involved which are
|
|
described in the following sections. Special directions are given for what
|
|
differs from FreeBSD ports for each file.
|
|
|
|
|
|
4.1 Makefile
|
|
============
|
|
|
|
Building, installation and creation of a binary package are all controlled
|
|
by the package's Makefile.
|
|
|
|
There is a Makefile for each package. This file includes the standard
|
|
bsd.pkg.mk file (referenced as "../../mk/bsd.pkg.mk"), which sets all the
|
|
definitions and actions necessary for the package to compile and install
|
|
itself. The mandatory fields are the DISTNAME which specifies the base name
|
|
of the distribution file to be downloaded from the site on the Internet,
|
|
MASTER_SITES which specifies that site, CATEGORIES which denotes the
|
|
categories into which the package falls, PKGNAME which is the name of the
|
|
package and the MAINTAINER name. This is so that anyone who quibbles with
|
|
the (always completely correct) decisions taken by the guy who maintains
|
|
the port can complain vigorously.
|
|
|
|
Currently the following values are available for CATEGORIES. If more than
|
|
one is used, they need to be separated by spaces:
|
|
|
|
archivers corba games meta-pkgs security
|
|
audio cross graphics misc shells
|
|
benchmarks databases lang net sysutils
|
|
cad devel mail news textproc
|
|
comms editors math plan9 www
|
|
converters emulators mbone print x11
|
|
|
|
See /usr/pkgsrc/mk/bsd.pkg.mk for a description of all available options
|
|
and variables.
|
|
|
|
Please pay attention to the following gotchas, especially when preparing a
|
|
package from the FreeBSD ports collection:
|
|
|
|
- Remove all MANx and CATx definitions from the package Makefile -
|
|
NetBSD has implemented automatic manual page handling, and these
|
|
definitions are now obsolete.
|
|
- Add MANCOMPRESSED (if not already there) if manpages are installed in
|
|
compressed form by the package; see comment in bsd.pkg.mk
|
|
- Replace /usr/local by ${PREFIX} in all files (see patches below)
|
|
- Rewrite any ldconfig commands as "ldconfig || ${TRUE}", as there isn't a
|
|
ldconfig command on all platforms NetBSD runs on (e.g. alpha).
|
|
- If modifying a package from the FreeBSD ports collection, preserve
|
|
their RCS ID: remove the '$'s around the FreeBSD RCS Id, and insert the
|
|
word FreeBSD, then add a <$>NetBSD<$> (Without the <>s, please remember
|
|
the Terminology section), i.e.:
|
|
|
|
before:
|
|
# <$>Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp <$>
|
|
|
|
after:
|
|
# <$>NetBSD<$>
|
|
# FreeBSD Id: Makefile,v 1.17 1997/06/16 06:39:51 max Exp
|
|
- If the package installs any info files, the main info directory file
|
|
needs to be updated to reflect this fact. NetBSD now has an INFO_FILES
|
|
definition, which is used to do this. For example, to install the
|
|
indent.info entry into the info directory file, simply use the
|
|
|
|
INFO_FILES= indent.info
|
|
|
|
definition in the package Makefile. If the package does this insertion
|
|
for you, you should specify USE_GTEXINFO in the package Makefile, to
|
|
ensure that the pre-requisite GNU texinfo package is installed on your
|
|
system.
|
|
- Adjust MAINTAINER to be either yourself, if you plan to maintain the
|
|
package for future updates, or set it to the default MAINTAINER
|
|
packages@netbsd.org, as it is unlikely that the FreeBSD people will
|
|
care about NetBSD packages.
|
|
- If there exists a home page for the software in question, please
|
|
add the variable HOMEPAGE right after MAINTAINER. The value of this
|
|
variable should be the URL for the home page.
|
|
|
|
4.2 files/*
|
|
===========
|
|
|
|
Most important, this directory contains the (mandatory) md5 checksum of all
|
|
the distfiles needed for the package to compile. This file - files/md5 -
|
|
contains an md5 checksum of the distribution file(s) to ensure that the
|
|
distfile retrieved from the Internet has not been altered by a malign force
|
|
to introduce a security hole or was corrupted during transfer. The file
|
|
contains the md5 checksum of the original distribution file used to create
|
|
the NetBSD package, from which any patches were generated etc. It can be
|
|
generated by hand using the md5(1) command or by invoking "make makesum".
|
|
|
|
Besides that, if you have any files that you wish to be placed in the
|
|
package prior to configuration or building, you could place these files
|
|
here and use a cp command in the pre-configure target to achieve this.
|
|
Alternatively, you could simply diff the file against /dev/null and use the
|
|
patch mechanism to manage the creation of this file.
|
|
|
|
|
|
4.3 patches/*
|
|
=============
|
|
|
|
This directory contains files that are used by the patch(1) command to
|
|
modify the sources as distributed in the distribution file into a form that
|
|
will compile and run perfectly on NetBSD. The files are applied
|
|
successively in alphabetic order (as returned by a shell "patches/patch-*"
|
|
glob expansion), so patch-aa is applied before patch-ab etc.
|
|
|
|
The patch-?? files should be in diff -u format. This is because (not only)
|
|
the FreeBSD ports tsar finds this format easier to read than context diffs,
|
|
and so you have more chance of getting your NetBSD package accepted as part
|
|
of the FreeBSD ports system if you format your diffs in a unified fashion.
|
|
|
|
Furthermore, do not put changes for more than one file into a single
|
|
patch-file, as this will make future modifications more difficult.
|
|
|
|
One important thing to mention is to pay attention that no RCS IDs get
|
|
stored in the patch files, as these will cause problems when later checked
|
|
into the NetBSD CVS tree. To avoid this, use the "-U 2" or -U 1" option to
|
|
diff.
|
|
|
|
When preparing a FreeBSD port for the NetBSD packages system, it's likely
|
|
that the FreeBSD port will work on NetBSD. However, check that the person
|
|
who ported the software to FreeBSD has not played fast and loose with the
|
|
__FreeBSD__ cpp definition without good cause - a simple way to do this is
|
|
to do
|
|
|
|
grep -i freebsd patches/patch-??
|
|
|
|
in the package directory.
|
|
|
|
Besides taking care of any FreeBSDisms, be sure to provide patches to
|
|
replace any occurance of /usr/local in any "Makefile"s in the original
|
|
package with ${PREFIX}.
|
|
|
|
|
|
4.4 pkg/*
|
|
=========
|
|
|
|
This directory contains several files used to manage the creation of binary
|
|
packages. Files from this directory are used in the binary package itself,
|
|
and will thus be installed on other machines, so you should be aware that
|
|
there is a wider audience than you might think for your comments and
|
|
witticisms.
|
|
|
|
4.4.1 Mandatory files
|
|
=====================
|
|
|
|
* pkg/COMMENT:
|
|
A one-line description of the piece of software. There is no need to
|
|
mention the package's name - this will automatically be added by the
|
|
pkg_* tools when they are invoked.
|
|
|
|
* pkg/DESCR:
|
|
A multi-line description of the piece of software. This should include
|
|
any credits where they are due. Please bear in mind that others do not
|
|
share your sense of humour (or spelling idiosyncracies), and that others
|
|
will read everything that you write here.
|
|
|
|
* pkg/PLIST:
|
|
This file governs the files that are installed on your system: all the
|
|
binaries, manual pages, etc. There are other directives which may be
|
|
entered in this file, to control the creation and deletion of
|
|
directories, and the location of inserted files.
|
|
|
|
If you're updating a FreeBSD package to work for NetBSD, please pay special
|
|
attention to the following things in pkg/PLIST:
|
|
|
|
- If there's a "@exec ldconfig ...", add an "@unexec ldconfig ...", so the
|
|
hints-file for ld.so doesn't grow without end.
|
|
- For @exec and @unexec rewrite any ldconfig-command as "ldconfig ||
|
|
/usr/bin/true", as there's no ldconfig command on some of the platforms
|
|
NetBSD runs on (e.g. alpha).
|
|
- Add any missing @dirrm statements
|
|
|
|
|
|
4.4.2 Optional files
|
|
====================
|
|
|
|
* pkg/INSTALL:
|
|
Shell script invoked twice during pkg_add. First time after package
|
|
extraction and before files are moved in place, the second time after
|
|
the files to install are moved in place. This can be used to do any
|
|
custom procedures not possible with @exec commands in PLIST. See
|
|
pkg_add(1) and pkg_create(1) for more information.
|
|
|
|
* pkg/DEINSTALL:
|
|
This script is executed before any files are removed. It is this
|
|
script's responsibility to clean up any additional messy details around
|
|
the package's installation, since all pkg_delete knows how to do is
|
|
delete the files created in the original distribution. See pkg_delete(1)
|
|
and pkg_create(1) for more information.
|
|
|
|
* pkg/REQ:
|
|
Require-script that is invoked before installation and de-installation
|
|
to ensure things like certain accounts being available, user/sysadmin
|
|
agreeing with usage policy, etc.
|
|
|
|
* pkg/MESSAGE
|
|
Display this file (using more(1)) after installing the package.
|
|
Useful for things like legal notices on almost-free software,
|
|
etc.
|
|
|
|
|
|
4.5 scripts/*
|
|
=============
|
|
|
|
This directory contains any files that are necessary for configuration of
|
|
your software, etc. If a script with any of the following names is present,
|
|
it will be executed at the appropriate time during the build process:
|
|
|
|
pre-fetch post-fetch
|
|
pre-extract post-extract
|
|
pre-patch post-patch
|
|
pre-configure post-configure configure
|
|
pre-build post-build
|
|
pre-install post-install
|
|
pre-package post-package
|
|
|
|
See section 7 for a description of the build process.
|
|
|
|
|
|
4.6 work/*
|
|
==========
|
|
|
|
When you type "make" the distribution files are unpacked into this
|
|
directory. It can be removed by typing
|
|
|
|
make clean
|
|
|
|
at the shell prompt. Also, this directory is used to keep various
|
|
timestamp files.
|
|
|
|
|
|
5 PLIST* issues
|
|
===============
|
|
|
|
This section addresses some special issues that one needs to take attention
|
|
of when dealing with the PLIST file (or files, see below!).
|
|
|
|
|
|
5.1 Miscellaneous
|
|
=================
|
|
|
|
* RCS Id:
|
|
Be sure to add a RCS ID line as the first thing in any PLIST file your
|
|
write:
|
|
|
|
@comment <$>NetBSD<$>
|
|
|
|
* ranlib:
|
|
Don't put any ranlib commands into your PLIST files, as they will cause
|
|
troubles when the package is removed. Just make sure the build-process
|
|
does run ranlib - it usually does - and you can leave this out. This is
|
|
usually only a problem when using ports from FreeBSD.
|
|
|
|
* ldconfig:
|
|
Don't put any ldconfig commands into your PLIST files, as they will
|
|
cause problems. All shared object caching is done automatically in
|
|
NetBSD (this takes place when you see the "Automatic shared object
|
|
handling" message), and so you can leave this out. If any shared
|
|
objects are found in the package, they will be dealt with
|
|
automatically, running ldconfig on platforms which need it, and not
|
|
otherwise. This is usually only a problem when using ports from
|
|
FreeBSD.
|
|
|
|
* ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH}:
|
|
Some packages like emacs and perl embed information about which
|
|
architecture they were built on into the pathnames where they install
|
|
their file. To handle this case, PLIST will be preprocessed before
|
|
actually used, and the symbol "${MACHINE_ARCH}" will be replaced by
|
|
what "sysctl -n hw.machine_arch" gives. The same is done if the string
|
|
${MACHINE_GNU_ARCH} is embedded in PLIST somewhere - use this on
|
|
packages that use GNU autoconfigure.
|
|
|
|
Legacy note: There used to be a symbol "<$ARCH>" that was replaced by
|
|
the output of "uname -m", but that's no longer supported and has been
|
|
removed.
|
|
|
|
* Manpage-compression:
|
|
Manpages should be installed in compressed form if MANZ is set (in
|
|
bsd.own.mk), and uncompressed otherwise. To handle this in the PLIST
|
|
file, the suffix ".gz" is appended/removed automatically for manpages
|
|
according to MANZ and MANCOMPRESSED being set or not, see above for
|
|
details. This modification of the PLIST file is done on a copy of it,
|
|
not pkg/PLIST itself.
|
|
|
|
|
|
5.2 MD/MI vs. general PLIST
|
|
===========================
|
|
|
|
Sometimes the packaging list in pkg/PLIST differs between platforms, e.g.
|
|
if one of them supports shared libs and the other does not. To address
|
|
this, a hook has been introduced into the NetBSD packages system to provide
|
|
a PLIST file defined on conditions set freely in the package's Makefile.
|
|
|
|
|
|
5.2.1 $PLIST_SRC
|
|
================
|
|
|
|
To use one or more files as source for the PLIST used in generating the
|
|
binary package, set the variable PLIST_SRC to the names of that file(s).
|
|
The files are later concatenated using cat(1), and order of things is an
|
|
important issue, see below.
|
|
|
|
|
|
5.2.2 PLIST-mi, PLIST-md.shared, PLIST-md.static
|
|
================================================
|
|
|
|
If PLIST_SRC is not set (the usual case), and if there is no pkg/PLIST, the
|
|
packages system looks for pkg/PLIST-mi, and pkg/PLIST-md.shared or
|
|
pkg/PLIST-md.static to handle differences due to the platform being able to
|
|
handle shared libs or not. PLIST-mi contains machine independent files,
|
|
PLIST-md.* contain machine dependent files, which may differ between
|
|
architectures that don't support dynamic libs/shared loading. Currently,
|
|
this is only used in the perl-packages, and as perl5 on alpha doesn't
|
|
support dynamic loading of extensions like perl/Tk yet, PLIST.mi-static is
|
|
also used on the alpha (besides pmax and powerpc). Alpha will hopefully be
|
|
removed soon when perl's fixed for dynamic loading.
|
|
|
|
(This handling of MI/MD PLIST files is implemented by setting PLIST_SRC to
|
|
either "PLIST-mi PLIST-md.static" or "PLIST-mi PLIST-md.shared", see
|
|
/usr/pkgsrc/mk/bsd.pkg.mk).
|
|
|
|
|
|
5.2.3 Order in the PLIST* file(s)
|
|
=================================
|
|
|
|
There is one gotcha regarding the ordering of @dirrm statements: any MI
|
|
@dirrm directives that follow any MD @dirrm's *must* go into the PLIST.md-*
|
|
files, as the files PLIST-mi and PLIST.md-{shared/static} are concatenated
|
|
in exactly this order. If the MI directory would be listed in PLIST-mi, it
|
|
would be removed before the MD directory, which wouldn't work.
|
|
|
|
E.g. if you have the following dirs:
|
|
foo/mi
|
|
foo/mi/md
|
|
|
|
then PLIST-mi contains:
|
|
<nothing>
|
|
|
|
and PLIST-md.* contain:
|
|
@dirrm foo/mi/md
|
|
@dirrm foo/mi
|
|
|
|
This will lead to some @dirrm statements being duplicated, but it's the
|
|
only way to ensure everything is properly removed. The same care must be
|
|
taken when PLIST_SRC is set to some package-specific settings.
|
|
|
|
|
|
6 Notes on fixes for packages
|
|
=============================
|
|
|
|
6.1 CPP defines
|
|
===============
|
|
|
|
To port an application to NetBSD, it's usually necessary for the compiler
|
|
to be able to judge the system on which it's compiling, and we use
|
|
definitions so that the C pre-processor can do this.
|
|
|
|
The really impatient should just note that a number of the FreeBSD ports
|
|
(which are called packages in the NetBSD world) rely on the CPP definition
|
|
__FreeBSD__. This should be used sparingly, for FreeBSD-specific features,
|
|
but unfortunately this is not always the case. A number also rely on the
|
|
fact that the CPU type is an Intel-based little-endian CPU.
|
|
|
|
To test whether you are working on a 4.4 BSD-derived system, you should use
|
|
the BSD definition, which is defined in <sys/param.h> on said systems.
|
|
Unfortunately, it may not always be appropriate to include that header file
|
|
without checking whether it's available:
|
|
|
|
#if (defined(__unix__) || defined(unix)) && !defined(USG)
|
|
#include <sys/param.h>
|
|
#endif
|
|
|
|
and then you can surround the BSD-specific parts of your port using the
|
|
conditional:
|
|
|
|
#if (defined(BSD) && BSD >= 199306)
|
|
...
|
|
#endif
|
|
|
|
Please use the __NetBSD__ definition sparingly - it should only apply to
|
|
features of NetBSD that are not present in other 4.4-lite derived BSDs.
|
|
|
|
You should also avoid defining __FreeBSD__=1 and then simply using the
|
|
FreeBSD port, if only from an aesthetic viewpoint.
|
|
|
|
|
|
6.2 Shared libraries - libtool
|
|
==============================
|
|
|
|
NetBSD supports many different machines, with different object formats
|
|
like a.out and ELF, and varying abilities to do shared library and
|
|
dynamic loading at all. To accompany this, verying commands and options
|
|
have to be passed to the compiler, linker etc. to get the Right Thing,
|
|
which can be pretty annoying esp. if you don't have all the machines at
|
|
your hand to test things. The "libtool" pkg can help here, as it just
|
|
"knows" how to build both static and dynamic libraries from a set our
|
|
source files, thus being platform independent.
|
|
|
|
To use "libtool", add a build-dependency on the libtool-pkg, then modify
|
|
the pkg's sources to use libtool for building it's libraries and add the
|
|
resulting patches to your pkg's patches-directory.
|
|
|
|
Here's how to use libtool in a pkg in seven simple steps:
|
|
|
|
1. Add USE_LIBTOOL= yes to the package Makefile.
|
|
|
|
2. For library objects, use "${LIBTOOL} --mode=compile ${CC}" in place of
|
|
${CC}. You could even add it to the definition of CC, if only
|
|
libraries are being built in a given Makefile. This one command will
|
|
build both PIC and non-PIC library objects, so you need not have
|
|
separate shared and non-shared library rules.
|
|
|
|
3. For the linking of the library, remove any "ar", "ranlib", and "ld
|
|
-Bshareable" commands, and use instead:
|
|
|
|
${LIBTOOL} --mode=link cc -o ${.TARGET:.a=.la} ${OBJS:.o=.lo} -rpath ${PREFIX}/lib -version-info major:minor
|
|
|
|
Note that the library is changed to have a .la extension, and the
|
|
objects are changed to have a .lo extension. Change OBJS as necessary.
|
|
This automatically creates all of the .a, .so.major.minor, and ELF
|
|
symlinks (if necessary) in the build directory.
|
|
|
|
4. When linking programs that depend on these libraries _before_ they are
|
|
installed, preface the cc or ld line with "${LIBTOOL} --mode=link", and
|
|
it will find the correct libraries (static or shared), but please be
|
|
aware that libtool will not allow you to specify a relative path in -L
|
|
(such as -L../somelib), because it is trying to force you to change
|
|
that argument to be the .la file. For example:
|
|
|
|
${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib
|
|
|
|
won't work; it needs to be changed to:
|
|
|
|
${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la
|
|
|
|
and it will DTRT with the libraries. If you *must* use a relative path
|
|
with -L, and you are not going to run this program before installing
|
|
it, you can omit the use of libtool during link and install of this
|
|
program if you add the subdirectory ".libs" in your -L command:
|
|
|
|
${CC} -o someprog -L../somelib/.libs -lsomelib
|
|
|
|
5. When installing libraries, preface the install or cp command with
|
|
"${LIBTOOL} --mode=install", and change the library name to .la. For
|
|
example:
|
|
|
|
${LIBTOOL} --mode=install ${BSD_INSTALL_DATA} ${SOMELIB:.a=.la} ${PREFIX}/lib
|
|
|
|
This will install the static .a, shared library, any needed symlinks,
|
|
and run "ldconfig."
|
|
|
|
6. In your PLIST, include the .a, .la, and .so.major.minor files. Don't
|
|
include the ELF symlink files; those are automatic.
|
|
|
|
FOR GNU PKGS THAT ALREADY SUPPORT LIBTOOL:
|
|
Add USE_LIBTOOL=yes to the package Makefile. You may possibly have to
|
|
modify the "configure" script not to check for or configure its own
|
|
libtool. See the libwww pkg, patch-ab, for the quick way to bypass
|
|
the pkg's own libtool.
|
|
|
|
|
|
6.3 Gotchas of FreeBSD ports
|
|
============================
|
|
|
|
See section 4.1 for Makefile issues (MANx, CATx, MANCOMPRESSED, ldconfig,
|
|
RCS IDs) and section 4.3 for gotchas on using patches from FreeBSD ports.
|
|
|
|
One of the biggest problems with FreeBSD ports is that too many of them
|
|
assume they will install into /usr/local, instead of regarding ${PREFX}
|
|
properly. To change this, add something like the following into your
|
|
package Makefile:
|
|
|
|
pre-configure:
|
|
for f in `find ${WRKDIR} -type f -print|xargs grep -l '/usr/local'`; do
|
|
\
|
|
${SED} -e 's:/usr/local:'${PREFIX}':g' < $$f > $$f.pdone && ${MV} $
|
|
$f.pdone $$f; \
|
|
done
|
|
|
|
This is taken from the sysutils/rtty package; be sure this works for your
|
|
package - it may actually make sense to look for some things in /usr/local,
|
|
for example. So don't blindly replace all occurrences of /usr/local!
|
|
|
|
Side note on manpages in PLIST: we don't regard any .gz suffix there, as
|
|
many FreeBSD ports seem to have .gz pages in PLIST even when they install
|
|
manpages without compressing them; rather, we add our own .gz suffix there
|
|
according to MANZ.
|
|
|
|
|
|
6.4 Feedback to the author
|
|
==========================
|
|
|
|
If you have found any bugs in the package you make available, if you had to
|
|
do special steps to make it run under NetBSD or if you enhanced the
|
|
software in various other ways, be sure to report these changes back to the
|
|
original author of that program! Only with that kind of support, the next
|
|
release of the program can incorporate these fixes, and also people not
|
|
using the NetBSD packages system can win from your efforts.
|
|
|
|
Support the idea of free software!
|
|
|
|
|
|
7 The build process
|
|
===================
|
|
|
|
The basic steps for building a program are always the same. First the
|
|
program's source (distfile) must be brought to the local system and
|
|
then extracted. After any patches to compile properly on NetBSD are
|
|
applied, the software can be configured, then built (usually by
|
|
compiling), and finally the produced binaries etc. can be put into
|
|
place on the system. These are exactly the steps performed by the
|
|
NetBSD package system, which is implemented as a series of targets in
|
|
a central Makefile, /usr/pkgsrc/mk/bsd.pkg.mk.
|
|
|
|
|
|
7.1 Program location
|
|
====================
|
|
|
|
Before outlining the process performed by the NetBSD package system in the
|
|
next section, here's a brief discussion on where programs are installed,
|
|
and which variables influence this.
|
|
|
|
The automatic variable PREFIX indicates where all files of the final
|
|
program shall be installed. It is usually set to $LOCALBASE (/usr/pkg),
|
|
or $CROSSBASE for pkgs in the "cross" category, though its value becomes
|
|
that of $X11BASE if USE_IMAKE, USE_MOTIF, or USE_X11 is set. The value
|
|
${PREFIX} needs to be put into the various places in the program's source
|
|
where paths to these files are encoded; see sections 4.3 and 6.2 for
|
|
details on this.
|
|
|
|
When choosing which of these variables to use, follow the following rules:
|
|
|
|
* ${PREFIX} always points to the location where the current pkg will be
|
|
installed. When referring to a pkg's own installation path, use ${PREFIX}.
|
|
|
|
* ${LOCALBASE} is where all non-X11 pkgs are installed. If you need to
|
|
construct a -I or -L argument to the compiler to find includes and
|
|
libraries installed by another non-X11 pkg, use ${LOCALBASE}.
|
|
|
|
* ${X11BASE} is where the actual X11 distribution is installed. When looking
|
|
for _standard_ X11 includes (not those installed by a pkg), use ${X11BASE}.
|
|
|
|
* X11 based pkgs are special in that they may be installed in either
|
|
X11BASE or LOCALBASE depending on a configuration option in /etc/mk.conf.
|
|
If you need to find includes or libraries installed by a pkg that has
|
|
USE_IMAKE, USE_MOTIF, or USE_X11 in its pkg Makefile, you need to use
|
|
_both_ of ${X11BASE} and ${LOCALBASE}.
|
|
|
|
|
|
7.2 Main targets
|
|
================
|
|
|
|
The main targets used during the build process defined in bsd.pkg.mk are:
|
|
|
|
* fetch:
|
|
This will check if the file(s) given in the variables DISTFILES and
|
|
PATCHFILES (as defined in the package's Makefile) are present on the
|
|
local system in /usr/pkgsrc/distfiles. If they are not present, they
|
|
will be fetched using ftp(1) from the site(s) given in the variable
|
|
MASTER_SITES. The location(s) in MASTER_SITES are in the form of URLs
|
|
and can be ftp://- and http://-URLs, as ftp(1) understands both of
|
|
them.
|
|
|
|
* checksum:
|
|
After the distfile(s) are fetched, their MD5 checksum is generated and
|
|
compared with the checksums stored in the files/md5 file. If the
|
|
checksums don't match, the build is aborted. This is to ensure the same
|
|
distfile is used for building, and that the distfile wasn't changed,
|
|
e.g. by some malign force or network lossage.
|
|
|
|
* extract:
|
|
When the distfiles are present on the local system, they need to be
|
|
extracted, as they are usually in the form of some compressed archive
|
|
format, most commonly .tar.gz. If only some of the distfiles need to be
|
|
uncompressed, the files to be uncompressed should be put into
|
|
EXTRACT_ONLY. If the distfiles are not in .tar.gz format, they can be
|
|
extracted by setting EXTRACT_CMD, EXTRACT_BEFORE_ARGS and/or
|
|
EXTRACT_AFTER_ARGS.
|
|
|
|
* patch:
|
|
After extraction, all the patches named by the PATCHFILES and those
|
|
present in the patches subdirectory of the package are applied.
|
|
Patchfiles ending in .Z or .gz are uncompressed before they are
|
|
applied, files ending in .orig or .rej are ignored. Any special
|
|
options to patch(1) can be handed in PATCH_DIST_ARGS. See section
|
|
4.3 for more details.
|
|
|
|
* configure:
|
|
Most pieces of software need information on the header files,
|
|
system calls, and library routines which are available in NetBSD.
|
|
This is the process known as configuration, and is usually
|
|
automated. In most cases, a script is supplied with the source,
|
|
and its invokcation results in generation of header files,
|
|
Makefiles, etc.
|
|
|
|
If the program doesn't come with its own configure script, one can be
|
|
placed in the package's scripts directory, called "configure". If so, it
|
|
is executed using sh(1).
|
|
|
|
If the program's distfile contains its own configure script, this can
|
|
be invoked by setting HAS_CONFIGURE. If the configure script is a GNU
|
|
autoconf script, GNU_CONFIGURE should be specified instead. In either
|
|
case, any arguments to the configure script can be specified in the
|
|
CONFIGURE_ARGS variable, and the configure script's name can be set in
|
|
CONFIGURE_SCRIPT if it differs from the default "configure".
|
|
|
|
If the program uses an Imakefile for configuration, the appropriate
|
|
steps can be invoked by setting USE_IMAKE to YES. (If you only want the
|
|
package installed in $X11BASE but xmkmf not being run, set USE_X11
|
|
instead!)
|
|
|
|
* build:
|
|
Once configuration has taken place, the software can be built on
|
|
NetBSD by invoking $MAKE_PROGRAM on $MAKEFILE with $ALL_TARGET as
|
|
the target to build. The default MAKE_PROGRAM is "gmake" if
|
|
USE_GMAKE is set, "make" otherwise. MAKEFILE is set to "Makefile"
|
|
by default, and ALL_TARGET defaults to "all". Any of these
|
|
variables can be set to change the default build process.
|
|
|
|
* install:
|
|
Once the build stage has completed, the final step is to install
|
|
the software in public directories, for users. As in the
|
|
build-target, $MAKE_PROGRAM is invoked on $MAKEFILE here, but with
|
|
the $INSTALL_TARGET instead, the latter defaulting to "install"
|
|
(plus "install.man", if USE_IMAKE is set).
|
|
|
|
If no target is specified, the default is "build". If a subsequent stage
|
|
is requested, all prior stages are made: e.g. "make build" will also
|
|
perform the equivalent of:
|
|
|
|
make fetch
|
|
make checksum
|
|
make extract
|
|
make patch
|
|
make configure
|
|
make build
|
|
|
|
|
|
7.3 Other helpful targets
|
|
=========================
|
|
|
|
* pre/post-*
|
|
For any of the main targets described in the previous section, two
|
|
auxiliary targets exist with "pre-" and "post-" used as a prefix
|
|
for the main target's name. These targets are invoked before and
|
|
after the main target is called, allowing extra configuration or
|
|
installation steps, for example, which program's configure script
|
|
or install target omitted. For any of these auxiliary targets,
|
|
scripts of the same name can be placed in the package's
|
|
scripts-subdirectory that will be executed at the given time, see
|
|
section 4.5.
|
|
|
|
* do-*:
|
|
Should one of the main targets do the wrong thing, and should there
|
|
be no variable to fix this, you can redefine it with the do-*
|
|
target. (Note that redefining the target itself instead of the
|
|
do-* target is a bad idea, as the pre-* and post-* targets won't be
|
|
called anymore, etc.) You will not usually ned to do this.
|
|
|
|
* reinstall:
|
|
If you did a "make install" and you noticed some file was not installed
|
|
properly, you can repeat the installation with this target, which will
|
|
ignore the "already installed" flag.
|
|
|
|
|
|
8 Debugging
|
|
===========
|
|
|
|
To check out all the gotchas when building a package from a FreeBSD port,
|
|
here are the steps that I do in order to get a package working. Please note
|
|
this is basically the same as what was explained in the previous sections,
|
|
only with some debugging aids.
|
|
|
|
- Retrieve port from FreeBSD collection
|
|
- Fix RCS-ID in the package's Makefile, see section 4.1.
|
|
- Import unchanged FreeBSD source (ONLY if you have cvs access, not needed
|
|
otherwise):
|
|
(cd .../pkgsrc/category/pkgname ; cvs import pkgsrc/category/pkgname \
|
|
FREEBSD FreeBSD-current-yyyy-mm-dd)
|
|
- If you did a CVS import, check it out to apply the following fixes
|
|
(not needed if you don't have CVS access!)
|
|
- Look at Makefile, fix if necessary; see section 4.1.
|
|
- Look at patches, remember if not appropriate
|
|
- Have a look at pkg/PLIST, add a "@comment <$>NetBSD<$>" line at the
|
|
beginning of any PLIST file (see section 5).
|
|
- make
|
|
- If something is not ok, fix; for patches: fix the file, then re-generate
|
|
the diff: 'diff -bu foo.orig foo >../../patches/patch-xx' (mv patch-xx
|
|
patch-xx.orig before); If there's no foo.orig from a previous patch, be
|
|
sure to have an old version of the file somewhere; re-iterate :)
|
|
- If all builds OK: touch /tmp/bla
|
|
- make install
|
|
- find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla >/tmp/x
|
|
(or whatever you set LOCALBASE and X11BASE to)
|
|
- pkg_delete blub
|
|
- find /usr/pkg/ /usr/X11R6/ -newer /tmp/bla: if this brings up any files,
|
|
they are missing in pkg/PLIST*; add them.
|
|
- Compare pkg/PLIST* against /tmp/x, fix the former one
|
|
( sort /tmp/x >/tmp/x2 ; sort pkg/PLIST >/tmp/P ; sdiff /tmp/x2 /tmp/P )
|
|
- make reinstall && make package
|
|
- pkg_delete blub
|
|
- "find /usr/pkg/ /usr/X11R6/ -type f -newer /tmp/bla" shouldn't find anything
|
|
now
|
|
- pkg_add .../blub.tgz
|
|
- Play with it :)
|
|
- pkg_delete - still no file should be left (re-run above find)
|
|
- submit (or commit, if you have cvs access); see section 10.
|
|
|
|
|
|
9 FAQs & features of the package system
|
|
=======================================
|
|
|
|
9.1 Packages using GNU autoconfig
|
|
=================================
|
|
|
|
If your package uses GNU autoconf, add the following to your package's
|
|
Makefile:
|
|
|
|
> GNU_CONFIGURE= yes
|
|
|
|
Note that this appends --prefix=${PREFIX} to CONFIGURE_ARGS, so you don't
|
|
have to do that yourself, and this may not be what you want.
|
|
|
|
|
|
9.2 Other distrib methods than .tar.gz
|
|
======================================
|
|
|
|
If your package uses a different distribution method from .tar.gz, take a
|
|
look at the package for plan9/sam, which uses a gzipped shell archive
|
|
(shar), but the quick solution is to set EXTRACT_SUFX to the name after the
|
|
DIST_NAME field, and add the following to your package's Makefile:
|
|
|
|
> EXTRACT_SUFX= .msg.gz
|
|
> EXTRACT_CMD= zcat
|
|
> EXTRACT_BEFORE_ARGS=
|
|
> EXTRACT_AFTER_ARGS= |sh
|
|
|
|
|
|
9.3 Packages not creating their own subdirectory
|
|
================================================
|
|
|
|
Your package doesn't create a subdirectory for itself (like GNU software
|
|
does, for instance), but extracts itself in the current directory: see
|
|
plan9/sam again, but the quick answer is:
|
|
|
|
> NO_WRKSUBDIR= yes
|
|
|
|
|
|
9.4 Custom configuration process
|
|
================================
|
|
|
|
Your package uses a weird Configure script: See the top package, but the
|
|
quick answer is:
|
|
|
|
> HAS_CONFIGURE= yes
|
|
> CONFIGURE_SCRIPT= Configure
|
|
> CONFIGURE_ARGS= netbsd13
|
|
|
|
|
|
9.5 Packages not building in their DIST_NAME directory
|
|
======================================================
|
|
|
|
Your package builds in a different directory from its base DIST_NAME - see
|
|
tcl and tk packages:
|
|
|
|
> WRKSRC= ${WRKDIR}/${DISTNAME}/unix
|
|
|
|
|
|
9.6 How to fetch all distfiles at once
|
|
======================================
|
|
|
|
You would like to download all the distfiles in a single batch from work or
|
|
university, where you can't run a "make fetch". But there's no archive of
|
|
the distfiles on ftp.netbsd.org and the one on ftp.freebsd.org contains
|
|
many distfiles for which there are no ports (yet).
|
|
|
|
The answer here is to do a "make fetch-list" in /usr/pkgsrc and use the
|
|
resulting list.
|
|
|
|
|
|
9.7 How to fetch files from behind a firewall
|
|
=============================================
|
|
|
|
If you are sitting behind a firewall, you must specify the relevant proxy
|
|
hosts to enable you to talk to other machines on the Internet which are not
|
|
behind your firewall. This is an environment variable in the form of a URL
|
|
e.g. in Amdahl, the machine orpheus.amdahl.com is one of the firewalls, and
|
|
it uses port 80 as the proxy port number. So the proxy environment
|
|
variables look like:
|
|
|
|
ftp_proxy=ftp://orpheus.amdahl.com:80/
|
|
http_proxy=http://orpheus.amdahl.com:80/
|
|
|
|
|
|
9.8 If your patch contains an RCS ID
|
|
====================================
|
|
|
|
See section 4.3 on how to remove RCS IDs from patch files.
|
|
|
|
|
|
9.9 How to pull in variables from /etc/mk.conf
|
|
==============================================
|
|
|
|
The problem with package-defined variables that can be overridden via
|
|
MAKECONF or /etc/mk.conf is that make(1) expands a variable as it is
|
|
used, but evaluates preprocessor like statements (.if, .ifdef and
|
|
.ifndef) as they are read. So, to use any variable (which may be set
|
|
in /etc/mk.conf) in one of the .if* statements, the file /etc/mk.conf
|
|
must be included before that .if* statement.
|
|
|
|
Rather than have a number of ad-hoc ways of including /etc/mk.conf,
|
|
should it exist, or MAKECONF, should it exist, include the
|
|
pkgsrc/mk/bsd.prefs.mk file in the package Makefile before any
|
|
preprocessor-like .if, .ifdef, or .ifndef statements:
|
|
|
|
.include "../../mk/bsd.prefs.mk"
|
|
|
|
.if defined(USE_MENUS)
|
|
...
|
|
.endif
|
|
|
|
|
|
9.10 Is there a mailing list for pkg-related discussion?
|
|
========================================================
|
|
|
|
Yes. We are using tech-pkg@netbsd.org for discussing package related
|
|
issues. To subscribe do:
|
|
|
|
echo subscribe tech-pkg | mail majordomo@netbsd.org
|
|
|
|
|
|
9.11 How do i tell "make fetch" to do passive FTP?
|
|
==================================================
|
|
|
|
Add the following to your /etc/mk.conf file: PASSIVE_FETCH=1
|
|
|
|
9.12 Dependencies on other packages
|
|
===================================
|
|
|
|
Your package may depend on some other package being present - and
|
|
there are various ways of expressing this dependency. NetBSD supports
|
|
the BUILD_DEPENDS, RUN_DEPENDS and DEPENDS definitions (beware: the
|
|
DEPENDS definition is not the same as FreeBSD's deprecated one, and
|
|
NetBSD does not use the FreeBSD LIB_DEPENDS definition any more - it
|
|
proved problematic on ELF NetBSD platforms).
|
|
|
|
[In the following examples, the BUILD_DEPENDS and RUN_DEPENDS
|
|
dependencies have the format: <file>:<directory containing package to
|
|
build>[:<stage>] If the <stage> isn't specified, it defaults to
|
|
``install''. If the file contains a '/', it is interpreted as a
|
|
regular file - otherwise, the name is taken to be an executable file,
|
|
and the PATH is searched for <file>. If the regular file is not
|
|
found, or the exectable file is not in the path, then the
|
|
pre-requisite package will be built from the sources in <directory
|
|
containing the package to build>. The DEPENDS definition specifies a
|
|
package name (which contains its version number), and the directory
|
|
containing the package to build if this version of the package is not
|
|
installed.]
|
|
|
|
(a) If your package needs files from another package to build, see the
|
|
print/ghostscript5 package (it relies on the jpeg sources being
|
|
present in source form during the build):
|
|
|
|
BUILD_DEPENDS= ../../graphics/jpeg/${WRKDIR:T}/jpeg-6a:../../graphics/jpeg:extract
|
|
|
|
(b) If your package needs to use another package to build itself, this
|
|
is specified using the BUILD_DEPENDS definition, but without
|
|
specifying the stage ``:extract'' in (a) above. An example is the
|
|
print/lyx package, which uses the latex binary during its build
|
|
process:
|
|
|
|
BUILD_DEPENDS= latex:../../print/teTeX
|
|
|
|
(c) If your package needs a library with which to link, this is
|
|
specified using the DEPENDS definition. An example of this is the
|
|
print/lyx package, which uses the xpm library, version 3.4j to build.
|
|
|
|
DEPENDS+= xpm-3.4j:../../graphics/xpm
|
|
|
|
(d) If your package needs some executable to be able to run correctly,
|
|
this is specified using the RUN_DEPENDS definition. The print/lyx
|
|
package needs to be able to execute the latex and ispell binaries when
|
|
it runs, and that is specified:
|
|
|
|
RUN_DEPENDS= latex:../../print/teTeX \
|
|
ispell:../../textproc/ispell
|
|
|
|
9.13 Conflicts with other packages
|
|
==================================
|
|
|
|
Your package may conflict with other packages a user might already have
|
|
installed on his system, e.g. if your package installs the same set of
|
|
files like another package in our pkgsrc tree.
|
|
|
|
In this case you can set CONFLICTS to a space seperated list of packages
|
|
(including version string) your package conflicts with.
|
|
|
|
For example pkgsrc/devel/cvs and pkgsrc/devel/cvs-current install both
|
|
the same files, thus you set in pkgsrc/devel/cvs/Makefile:
|
|
|
|
CONFLICTS= cvs-1.9.26 cvs-1.9.27 cvs-1.9.28
|
|
|
|
and in pkgsrc/devel/cvs-current/Makefile:
|
|
|
|
CONFLICTS= cvs-1.9 cvs-1.9.26 cvs-1.9.27
|
|
|
|
assuming that cvs is version 1.9 and cvs-current is cvs-1.9.28, and we had
|
|
already cvs-1.9.26 and cvs-1.9.27 in our pkgsrc tree.
|
|
|
|
9.14 Software which has a WWW Home Page
|
|
=======================================
|
|
|
|
The NetBSD packages system now supports a variable called HOMEPAGE.
|
|
If the software being packaged has a home page, the Makefile should
|
|
include the URL for that page in the HOMEPAGE variable. The definition
|
|
of the variable should be placed immediately after the MAINTAINER
|
|
variable.
|
|
|
|
10 Submitting
|
|
=============
|
|
|
|
* precompiled binary packages:
|
|
Please contact us for directions on how to provide your precompiled
|
|
binary packages.
|
|
[XXX - need more info here - do we have a incoming-dir for such things
|
|
on ftp.netbsd.org? - hubertf]
|
|
|
|
* packages:
|
|
First, check that your package is complete, compiles and runs well; see
|
|
section 8 and the rest of this document. Then, generate a gzipped
|
|
tar-file of all the files needed for the package, preferably with all
|
|
files in a single directory. Place this tar-file to a place where the
|
|
package maintainers can fetch it using FTP or HTTP (WWW). Finally,
|
|
send-pr with category "pkg", a short description of your package
|
|
(contents of pkg/COMMENT are OK), plus the URL of your tar-file.
|
|
|
|
You will be notified if your send-pr has been addressed so you can remove
|
|
the tar-file.
|
|
|
|
|
|
11 A simple example of a package: bison
|
|
=======================================
|
|
|
|
I checked to find a piece of software that isn't in the FreeBSD ports
|
|
collection, and picked GNU bison. Quite why someone would want to have
|
|
bison when Berkeley yacc is already present in the tree is beyond me, but
|
|
it's useful for the purposes of this exercise.
|
|
|
|
|
|
11.1 files
|
|
==========
|
|
|
|
The file contents in this section must be used without the "> " prefix.
|
|
|
|
|
|
11.1.1 Makefile
|
|
===============
|
|
|
|
> # <$>NetBSD<$>
|
|
>
|
|
> DISTNAME= bison-1.25
|
|
> CATEGORIES= devel
|
|
> MASTER_SITES= ${MASTER_SITE_GNU}
|
|
>
|
|
> MAINTAINER= thorpej@netbsd.org
|
|
> HOMEPAGE= http://www.gnu.org/software/bison/bison.html
|
|
>
|
|
> GNU_CONFIGURE= yes
|
|
> INFO_FILES= bison.info
|
|
>
|
|
> .include "../../mk/bsd.pkg.mk"
|
|
|
|
|
|
11.1.2 pkg/COMMENT
|
|
==================
|
|
|
|
> GNU yacc clone.
|
|
|
|
|
|
11.1.3 pkg/DESCR
|
|
================
|
|
|
|
> GNU version of yacc. Can make re-entrant parsers, and numerous other
|
|
> improvements. Why you would want this when Berkeley yacc(1) is part
|
|
> of the NetBSD source tree is beyond me.
|
|
|
|
|
|
11.1.4 pkg/PLIST
|
|
================
|
|
|
|
> @comment <$>NetBSD<$>
|
|
> bin/bison
|
|
> man/man1/bison.1.gz
|
|
> @unexec %D/bin/install-info --delete %D/info/bison.info %D/info/dir
|
|
> info/bison.info
|
|
> info/bison.info-1
|
|
> info/bison.info-2
|
|
> info/bison.info-3
|
|
> info/bison.info-4
|
|
> info/bison.info-5
|
|
> @exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir
|
|
> @exec %D/bin/install-info %D/info/bison.info %D/info/dir
|
|
> share/bison.simple
|
|
> share/bison.hairy
|
|
|
|
|
|
11.1.5 Checking a package "pkglint"
|
|
===================================
|
|
|
|
The NetBSD package system comes with a tool called "pkglint" (located in the
|
|
directory "pkgsrc/devel/pkglint") which helps to check the contents of these
|
|
files. After installation it is quite easy to use, just change to the
|
|
directory of the package you which to examine and execute "pkglint":
|
|
|
|
> tron@lyssa:/usr/pkgsrc/devel/bison>pkglint
|
|
> OK: checking pkg/COMMENT.
|
|
> OK: checking pkg/DESCR.
|
|
> OK: checking Makefile.
|
|
> OK: checking files/md5.
|
|
> OK: checking patches/patch-aa.
|
|
> looks fine.
|
|
|
|
Depending on the supplied command line arguments (see "man pkglint") more
|
|
intensive checks will be performed. Use e.g. "portlint -a -v" for a very
|
|
detailed and verbose check.
|
|
|
|
|
|
11.2 Steps for building, installing, packaging
|
|
==============================================
|
|
|
|
Create the directory where the package lives, plus any auxiliary directories:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang(1765)# cd /usr/pkgsrc/lang
|
|
> root@pumpy:/u/pkgsrc/lang(1765)# mkdir bison
|
|
> root@pumpy:/u/pkgsrc/lang(1766)# cd bison
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1768)# mkdir files patches pkg
|
|
|
|
Create Makefile, pkg/COMMENT, pkg/DESCR and pkg/PLIST as in section 11.1,
|
|
then continue with fetching the distfile:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1769)# make fetch
|
|
> >> bison-1.25.tar.gz doesn't seem to exist on this system.
|
|
> >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//.
|
|
> Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
|
|
> ftp: Error retrieving file: 500 Internal error
|
|
>
|
|
> >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//.
|
|
> Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
|
|
> ftp: Error retrieving file: 500 Internal error
|
|
>
|
|
> >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//.
|
|
> Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/)
|
|
> Successfully retrieved file.
|
|
|
|
Generate the checksum of the distfile into files/md5:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1770)# make makesum
|
|
|
|
Now compile:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1777)# make
|
|
> >> Checksum OK for bison-1.25.tar.gz.
|
|
> ===> Extracting for bison-1.25
|
|
> ===> Patching for bison-1.25
|
|
> ===> Ignoring empty patch directory
|
|
> ===> Configuring for bison-1.25
|
|
> creating cache ./config.cache
|
|
> checking for gcc... cc
|
|
> checking whether we are using GNU C... yes
|
|
> checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin
|
|
> checking how to run the C preprocessor... cc -E
|
|
> checking for minix/config.h... no
|
|
> checking for POSIXized ISC... no
|
|
> checking whether cross-compiling... no
|
|
> checking for ANSI C header files... yes
|
|
> checking for string.h... yes
|
|
> checking for stdlib.h... yes
|
|
> checking for memory.h... yes
|
|
> checking for working const... yes
|
|
> checking for working alloca.h... no
|
|
> checking for alloca... yes
|
|
> checking for strerror... yes
|
|
> updating cache ./config.cache
|
|
> creating ./config.status
|
|
> creating Makefile
|
|
> ===> Building for bison-1.25
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g LR0.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g allocate.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g closure.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g conflicts.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c
|
|
> cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\" -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -g ./files.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lex.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c
|
|
> cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c
|
|
> cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o
|
|
getopt.o getopt1.o
|
|
> ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp()
|
|
> rm -f bison.s1
|
|
> sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1
|
|
|
|
Everything seems OK, so install the files:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1785)# make install
|
|
> >> Checksum OK for bison-1.25.tar.gz.
|
|
> ===> Installing for bison-1.25
|
|
> sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1
|
|
> rm -f /usr/pkg/bin/bison
|
|
> cd /usr/pkg/share; rm -f bison.simple bison.hairy
|
|
> rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info*
|
|
> install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison
|
|
> /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple
|
|
> /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy
|
|
> cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done
|
|
> /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1
|
|
> ===> Registering installation for bison-1.25
|
|
|
|
You can now use bison, and also - if you decide so - remove it with
|
|
"pkg_delete bison-1.25". Should you decide that you want a binary package,
|
|
do this now:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1786)# make package
|
|
> >> Checksum OK for bison-1.25.tar.gz.
|
|
> ===> Building package for bison-1.25
|
|
> Creating package bison-1.25.tgz
|
|
> Registering depends:.
|
|
> Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz'
|
|
|
|
Now that you don't need the source and object files any more, clean up:
|
|
|
|
> root@pumpy:/u/pkgsrc/lang/bison(1787)# make clean
|
|
> ===> Cleaning for bison-1.25
|
|
|
|
|
|
======================
|
|
Appendix A: build logs
|
|
======================
|
|
|
|
A.1 Building top
|
|
================
|
|
|
|
> Script started on Fri Oct 3 13:22:31 1997
|
|
> root@pumpy:/u/pkgsrc/sysutils/top(1342)# make
|
|
> >> top-3.5beta5.tar.gz doesn't seem to exist on this system.
|
|
> >> Attempting to fetch from ftp://ftp.groupsys.com/pub/top/.
|
|
> Requesting ftp://ftp.groupsys.com/pub/top/top-3.5beta5.tar.gz (via ftp://orpheus.amdahl.com:80/)
|
|
> Successfully retrieved file.
|
|
> >> Checksum OK for top-3.5beta5.tar.gz.
|
|
> ===> Extracting for top-3.5beta5
|
|
> ===> Patching for top-3.5beta5
|
|
> ===> Applying NetBSD patches for top-3.5beta5
|
|
> ===> Configuring for top-3.5beta5
|
|
> /bin/cp /u/pkgsrc/sysutils/top/files/defaults /u/pkgsrc/sysutils/top/work/top-3.5beta5/.defaults
|
|
> chmod a-x /u/pkgsrc/sysutils/top/work/top-3.5beta5/install
|
|
>
|
|
> Reading configuration from last time...
|
|
>
|
|
> Using these settings:
|
|
> Bourne Shell /bin/sh
|
|
> C compiler cc
|
|
> Compiler options -DHAVE_GETOPT -O
|
|
> Awk command awk
|
|
> Install command /usr/bin/install
|
|
>
|
|
> Module netbsd13
|
|
> LoadMax 5.0
|
|
> Default TOPN -1
|
|
> Nominal TOPN 18
|
|
> Default Delay 2
|
|
> Random passwd access yes
|
|
> Table Size 47
|
|
> Owner root
|
|
> Group Owner kmem
|
|
> Mode 2755
|
|
> bin directory $(PREFIX)/bin
|
|
> man directory $(PREFIX)/man/man1
|
|
> man extension 1
|
|
> man style man
|
|
>
|
|
> Building Makefile...
|
|
> Building top.local.h...
|
|
> Building top.1...
|
|
> Doing a "make clean".
|
|
> rm -f *.o top core core.* sigdesc.h
|
|
> To create the executable, type "make".
|
|
> To install the executable, type "make install".
|
|
> ===> Building for top-3.5beta5
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c top.c
|
|
> awk -f sigconv.awk /usr/include/sys/signal.h >sigdesc.h
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c commands.c
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c display.c
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c screen.c
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c username.c
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c utils.c
|
|
> utils.c: In function `errmsg':
|
|
> utils.c:348: warning: return discards `const' from pointer target type
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c version.c
|
|
> cc -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c getopt.c
|
|
> cc "-DOSREV=12G" -DHAVE_GETOPT -DORDER -DHAVE_GETOPT -O -c machine.c
|
|
> rm -f top
|
|
> cc -o top top.o commands.o display.o screen.o username.o utils.o version.o getopt.o machine.o -ltermcap -lm -lkvm
|
|
> root@pumpy:/u/pkgsrc/sysutils/top(1343)# make install
|
|
> >> Checksum OK for top-3.5beta5.tar.gz.
|
|
> ===> Installing for top-3.5beta5
|
|
> /usr/bin/install -o root -m 2755 -g kmem top /usr/pkg/bin
|
|
> /usr/bin/install top.1 /usr/pkg/man/man1/top.1
|
|
> strip /usr/pkg/bin/top
|
|
> ===> Registering installation for top-3.5beta5
|
|
> root@pumpy:/u/pkgsrc/sysutils/top(1344)#
|
|
|
|
|
|
A.2 Packaging top
|
|
=================
|
|
|
|
> root@pumpy:/u/pkgsrc/sysutils/top(1344)# make package
|
|
> >> Checksum OK for top-3.5beta5.tar.gz.
|
|
> ===> Building package for top-3.5beta5
|
|
> Creating package top-3.5beta5.tgz
|
|
> Registering depends:.
|
|
> Creating gzip'd tar ball in '/u/pkgsrc/sysutils/top/top-3.5beta5.tgz'
|
|
> root@pumpy:/u/pkgsrc/sysutils/top(1345)#
|
|
|
|
|
|
======================================================
|
|
Appendix B: Layout of the FTP server's package archive
|
|
======================================================
|
|
|
|
Layout for precompiled binary packages on ftp.netbsd.org:
|
|
|
|
/pub/NetBSD/packages/
|
|
README
|
|
distfiles/
|
|
pkgsrc -> /pub/NetBSD/NetBSD-current/pkgsrc
|
|
1.3/
|
|
i386/
|
|
All/
|
|
archivers/
|
|
foo -> ../All/foo
|
|
...
|
|
m68k/
|
|
All/
|
|
archivers/
|
|
foo -> ../All/foo
|
|
...
|
|
amiga -> m68k
|
|
atari -> m68k
|
|
...
|
|
|
|
|
|
To create:
|
|
- cd /usr/pkgsrc ; make install ; make package
|
|
- upload /usr/pkgsrc/packages to
|
|
ftp://ftp.netbsd.org/pub/NetBSD/packages/`uname -r`/`sysctl -n hw.machine_arch`
|
|
- if necessary ln -s `sysctl -n hw.machine` `sysctl -n hw.machine_arch`
|
|
|
|
Disk space needed: unknown.
|
|
|
|
|
|
###########################################################################
|
|
# Local Variables:
|
|
# mode: Text
|
|
# fill-column: 75
|
|
# sentence-end-double-space: nil
|
|
# End:
|