File: [local] / www / Attic / checklist.html (download) (as text)
Revision 1.55, Fri Jan 2 02:51:54 2004 UTC (20 years, 5 months ago) by jose
Branch: MAIN
Changes since 1.54: +2 -2 lines
bump copyrights to 2004, ok nick@
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="resource-type" content="document">
<meta name="description" CONTENT="How to make/update an OpenBSD port.">
<meta name="keywords" content="openbsd,ports">
<meta name="distribution" content="global">
<meta name="copyright" content="This document copyright 1998-2004 by OpenBSD.">
<title>OpenBSD Porting Checklist</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#23238E">
<a href="index.html"><img alt="[OpenBSD]" height="30" width="141" src="images/smalltitle.gif" border="0"></a>
<h2><font color="#e00000">OpenBSD Porting Checklist</font></h2>
This document describes how to make or upgrade a port. It is a useful
reminder of things to do. This is neither totally accurate nor perfect.
Direct comments and questions to <a href="mailto:ports@openbsd.org">
ports@openbsd.org</a>.
<hr>
<ol>
<li>
If you want to be a maintainer, subscribe to
<a href="mailto:ports@openbsd.org">ports@openbsd.org.</a>
<ul><li>
This is where all ports discussions take place.
<li>
Reading this list is important since many announcements go over this list.
<li>
You will find a lot of porting-savvy people there. They can often give you
good advice or test ports for you.
</ul>
<br><li>
Being a maintainer means <strong>more</strong> than just submitting ports.
It also means trying to keep them up-to-date, and to answer questions about
them.
<br><br><li>
Check out a copy of the ports tree from cvs.
You can find instructions on how to do this at
<a href="http://www.openbsd.org/anoncvs.html">
http://www.openbsd.org/anoncvs.html</a>.
<br><br><li>
Pick a place to put your port and create the basic
infrastructure there. Use the template Makefile at
<code>/usr/ports/infrastructure/templates/Makefile.template</code>.
NEED_VERSION is obsolete and should not be used in new ports.
As you are a port developer, you are supposed to update
your ports tree, including bsd.port.mk.
<ul><li>
Create the directory <code>pkg</code>.
<li>
Create the empty files <code>pkg/DESCR, pkg/PLIST</code>.
</ul>
<br><li>
Add the fetch portions of the Makefile.
<ul><li>
Fill in EXTRACT_SUFX if it's anything besides .tar.gz. Other examples are
.tar.Z, or .tgz.
<li>
Fill in DISTNAME which is the name of the file minus the extract suffix.
E.g., if you have foo-1.0.tar.gz, DISTNAME is foo-1.0.
<li>
Fill in MASTER_SITES which is a URL to the directory where the distfile
is kept. E.g., ftp://ftp.openbsd.org/pub/OpenBSD/distfiles/.
<strong>Don't forget the trailing slash.</strong>
Try to have at least three distinct sites as well.
Place the most easily accessible first as they are traversed in order.
<li>
Keep in mind that fetch references the file as
${MASTER_SITES}${DISTNAME}${EXTRACT_SUFX}. All three are used. Don't
set DISTNAME to point to the file directly.
<li>
You can check to see if you have filled these values in correctly by typing
<b>make fetch-all</b>.
</ul>
<p>
For more complex ports, you have more options and tools available to you:
<ul><li>
You also have the variable PATCHFILES available. This is a list of vendor
(not OpenBSD) patches to the port. Common uses are things like security
or reliability fixes.
<li>
If your ports are available over large public mirrors such as GNU, SunSite, or
CPAN, we have already provided a list of sites for your use in
/usr/ports/infrastructure/templates/network.conf.template.
Set MASTER_SITES to ${MASTER_SITE_GNU}, or ${MASTER_SITE_SUNSITE}, etc.
To simplify this process, use the construct ${MASTER_SITE_FOO:=subdir/} to
append the distribution subdirectory.
<li>
Ports normally correspond to given versions of software. Once they are retrieved, files are checksummed and compared to the recorded
checksum(s) in distinfo. So, to avoid confusion, DISTFILES and PATCHFILES should have clearly visible version numbers:
don't retrieve foo-latest.tar.gz if it is a link to foo-1.0.5.tar.gz. If necessary, gently ask the original program author
to make such distinctions clear.
<li>
If a given port needs more than about 5 DISTFILES + PATCHFILES to work, use DIST_SUBDIR to avoid cluttering
/usr/ports/distfiles too much.
<li>
DIST_SUBDIR must not include version numbers. When the port is updated to a later version, some distfiles may not change, but will be
refetched if DIST_SUBDIR is changed. Even if all distfiles change, it is easier for the user to track cruft.
<li>
All DISTFILES and PATCHFILES don't necessarily come from the same set of MASTER_SITES. Supplementary sites can be
defined using the variables MASTER_SITES0 to MASTER_SITES9. Just write DISTFILES=foo-1.0.5.tar.gz:5 to
retrieve foo-1.0.5.tar.gz from MASTER_SITES5.
<li>
Some ports don't always need to retrieve all files in all circumstances. For instance, some ports may have some compilation options, and
associated files which are only required in such a case. Or they may need some files for some architectures only. In such a case, those
supplementary optional files must be mentioned in the SUPDISTFILES variable. Targets such as makesum or
mirror-distfiles will fetch those supplementary files that the casual user doesn't need.
</ul>
<br><li>
Create a checksum in <i>distinfo</i> by typing <b>make makesum</b>.
Then verify the checksum is correct by typing <b>make checksum</b>.
<ul><li>
In some rare cases, files checksums can't be verified reliably. By all means, porters should try to find sites that are reliable. Communicating
with the software author and the archive site maintainer at this stage is highly desirable. In the worst case, non-checksummable files can be
mentioned in the IGNOREFILES variable.
<li>
All files in DISTFILES are usually processed during make extract. EXTRACT_ONLY may be used to limit extraction to a
subset of files (possibly empty). The customary use of this variable is to customize extraction: for instance, if some DISTFILES need
some special treatment, they will be removed from EXTRACT_ONLY and handled manually at post-extract stage.
For historic reasons, make extract does set up the working directory first along with extracting files. Thus, providing a
pre-extract or a do-extract target is highly unusual (and fairly suspicious behavior, indicative of a high degree of obfuscation
in the port).
<li>
Patches that need specific treatment should be mentioned in DISTFILES, and removed from EXTRACT_ONLY, for historic reasons.
</ul>
<br><li>
Extract the port with <b>make extract</b>. Pay attention to where the base
of the sources are. Usually, it's <i>w-${PKGNAME}${FLAVOR_EXT}/${DISTNAME}</i>. You may need to
modify the Makefile's WRKDIST variable if it is different.
<br><br><li>
Read the installation documentation and note what you have to do to build
the port and any special options that might be needed.
<br><br><li>
Now is also a good time to figure out what kind of licensing restrictions
apply to your port. Many are freely redistributable but then again, quite
a few are not. We need four questions answered to distribute ports
properly. These are the PERMIT_* values in the Makefile.
<ul><li>
PERMIT_PACKAGE_CDROM tells us if we can put the package on the cdrom.
<li>
PERMIT_PACKAGE_FTP tells us if we can put the package on the ftp sites.
<li>
PERMIT_DISTFILES_CDROM tells us if we can mirror the distfiles on the cdrom.
<li>
PERMIT_DISTFILES_FTP tells us if we can mirror the distfiles on the ftp sites.
</ul>
<p>
Set these values to Yes if it is permitted or to a comment string stating why
it is not. Pay attention to any special conditions you may need to fulfill
later on. E.g., some ports require to install a copy of the license. We
recommend you place the license in <code>/usr/local/share/DISTNAME/</code>.
<br><br><li>
Add configuration options to Makefile and/or create the configuration script.
<ul><li>
You can add a port configuration script named `configure' to a directory
named <code>scripts/</code>. This will be run before any configuration
specified by CONFIGURE_STYLE is run.
<li>
If GNU configure is used you may want to run ./configure --help
to see what options are available.
<li>
Anything that you may want to override can be changed by adding the
--option flags to the CONFIGURE_ARGS parameter in the Makefile.
<li>
Use CONFIGURE_ARGS+= to append to the variable. CONFIGURE_ARGS= will
overwrite it.
</ul>
<br><li>
Try building the port with <b>make build</b>.
<ul><li>
If you're lucky, the port will go all the way through without errors.
<li>
If it exits with an error, you will need to generate patches for your port.
Figure out what needs to be changed and make a patch for it.
<li>
Patches must be relative to ${WRKDIST}.
<li> The easiest way to reset the port and test your patches is
<b>make clean patch</b>. This will delete the work directory, re-extract,
and patch your port.
</ul>
<br><li>
Begin and cycle of <b>make build</b>, generate a patch (or use <b>make
update-patches</b>), and
<b>make clean patch</b>.
<ul><li>
Patches go in the directory <i>patches/</i> and should be named patch-* with
* being something meaningful. We recommend you name your patches
patch-FILENAME where FILENAME is the name of the file it is patching.
(<tt>make update-patches</tt> does this automatically for you.)
<li>
Applying PATCHFILES is the first half of the make patch stage. It can be
invoked separately as make distpatch, which is a convenient target for
porters. Ignore this if you haven't set it.
<li>
Only patch one source file per patchfile, please.
<li>
Use <b>make update-patches</b> to generate patches.
<li>
All patches MUST be relative to ${WRKDIST}.
<li>
Check that patches <strong>DON'T</strong> contain tags that cvs
will replace. If they do, your patches won't apply after you check
them in. You can check in your changes with -kk to avoid this.
<li>
Write a small explanation at the beginning of the patchfile about its purpose
(not mandatory).
<li>
<b>Please</b> feed your patches back to the author of that piece of software.
</ul>
<br><li>
Try setting <code>SEPARATE_BUILD</code>.
<ul><li>
If the port can build with object files outside its source tree,
this is cleaner (many programs using <code>CONFIGURE_STYLE=gnu</code> can),
and may help people who mount their ports tree on several arches.
<li>
This can also spare you some effort, as you will possibly be able to
restart the cycle at <code>configure</code> most of the time.
</ul>
<br><li>
Peruse the output (if any) and tweak any options in the Makefile.
To repeat issue the command `<b>make clean configure</b>'.
<p>
Note: make sure host-dependent files go in <i>/etc</i> or
<i>/etc/<name></i>, but <strong>NEVER REPLACE OR MODIFY</strong>
existing files in <i>/etc</i>. Best to have install place them
in <i>/usr/local/share/<name></i> and then copy to
<i>/etc</i> or <i>/etc/<name></i> only if the files do not exist.
If the files exist, display a message that says such-and-such files need
to be modified. This also guarantees that the files will be included in
the package since everything under <i>/usr/local</i> is included in the PLIST.
After a package has been installed the contents of <code>pkg/MESSAGE</code>
will be displayed if it exists.
<p>
The OpenBSD file locations are:
<pre>
user executables: /usr/local/bin
system admin executables: /usr/local/sbin
program executables: /usr/local/libexec
libraries /usr/local/lib
architecture dependent data /usr/local/lib/<name>
installed include files: /usr/local/include or
/usr/local/include/<name>
single-machine data: /etc or /etc/<name>
local state: /var/run
games score files: /var/games
GNU info files: /usr/local/info
man pages: /usr/local/man/...
read-only architecture-independent: /usr/local/share/<name>
misc documentation: /usr/local/share/doc/<name>
</pre>
<li>
Begin a cycle of makes until the port is ready. Patch (see above)
clean, and make until the port is generated. Get rid of all warnings
if possible, especially security related warnings.
<br><br><li>
Control SEPARATE_BUILD semantics.
You have to do this only if the port builds with
SEPARATE_BUILD defined.
Ideally, the port should not modify any file in
${WRKSRC} after <b>make patch</b>.
You can check this by making sure you don't have any write access
to ${WRKSRC}. Then you can set
<code>SEPARATE_BUILD=concurrent</code> -- someone can use the same
source tree to build on distinct arches simultaneously.
Otherwise, set <code>SEPARATE_BUILD=simple</code> -- building on
distinct arches simultaneously may be met with problems, as some
source files may be regenerated at awkward moments.
<br><br><li>
Add <i>COMMENT</i> in Makefile.
COMMENT is a <strong>SHORT</strong> one-line description of the port
(max. 60 characters). Do <strong>NOT</strong> include the package
name (or version number of the software) in the comment.
Do <strong>NOT</strong> start with an uppercase letter
unless semantically significant, and
do <strong>NOT</strong> end with a period.
<strong>DON'T EVER START WITH AN INDEFINITE ARTICLE SUCH AS `a' or `an';
remove the article altogether.</strong>
<br><br><li>
Edit <i>pkg/DESCR</i>, <i>pkg/PLIST</i>.
<ul><li>
DESCR is a longer description of the port. One to a few paragraphs
concisely explaining what the port does is sufficient. It is also advised to
wrap your lines at 72 characters. This can be done by first editing the DESCR
file and then running it through 'fmt -w 72'.
<li>
PLIST is kept empty at this point.
</ul>
<br><li>
If the application needs to create a user or a group, choose the lowest free
id from <code>/usr/ports/infrastructure/db/user.list</code> for your port to
use and make sure your port gets added to this file at commit time.
<br><br><li>
Install the application with <b>make install</b>.
If the port installs dynamic libraries, check their symbol tables
with <code>nm</code>, as some mistaken software strips dynamic libraries,
which may lead to weird failures later. On the other hand, executable binaries
SHOULD be stripped; <code>file</code> can be used to determine this. If the
port already contains code for stripping binaries, use it (i.e., an
'install-strip' target); otherwise, add a provision in the port Makefile.
<br><br><li>
<strong>Check port for security holes again</strong>. This is
especially important for network and setuid programs. See
<a href="porting.html#Security">our security recommendations</a>
for that. Log interesting stuff and fixes in the
<code>pkg/SECURITY</code> file. This file
should list audited potential problems, along with relevant patches,
so that another person can see at first glance what has been done.
Example:
<pre>
$OpenBSD$
${WRKDIR}/receiver.c
call to mktemp (wrapper function do_mktemp) does seem to be correct.
The server makes extensive use of strlcpy/strlcat/snprintf.
</pre>
<li>
Create pkg/PLIST. After the install is complete use the developer's command,
<b>make plist</b> which makes the file PLIST in the <i>pkg</i> directory.
This file is a candidate packing list.
<p>
Beware! The files are found by timestamp. This means it does NOT:
<ul><li>
list any files installed with `tar' as their timestamp
will not change and thus won't be found by `find'.
<li>
Update the <code>info/dir</code> file if .info files are added.
Also, be sure that the <code>info/dir</code> is not part of the PLIST.
<li>
Try to do anything special with links or symbolic links. A
cursory test of tar shows it does the right thing with links
and symbolic links so I don't see why we need to special case
anything in the packing list. But still...
</ul>
<p>
Peruse `PLIST' and verify that everything was installed and
that it was installed in the proper locations. Anything not installed
can be added to a port Makefile `post-install' rule.
<p>
Ports that install shared libraries will have another file called PFRAG.shared.
<ul><li>
PLIST describes the files being independent of whether the architecture supports shared libraries or not.
<li>
PFRAG.shared describes only the files being additionally installed on those architectures that support
shared libraries.
<li>
PFRAG.noshared describes only the files being additionally installed on architectures that do not
support shared libraries.
</ul>
<br><li>
Keep repeating uninstall and reinstall until perfect.
<em>Perfect</em> is when everything installs and uninstalls
in its proper location. `pkg_delete <pkg_name>' is
used to uninstall. `sudo make reinstall' is used to reinstall. See the
`pkg_create' man page for other commands that may be added
to PLIST to ensure all is cleaned up. After an uninstall the command:
<pre>
$ find /usr/local -newer w-${PKGNAME}${FLAVOR_EXT}/fake-${MACHINE_ARCH}[-${FLAVOR}]/.install_started -print
</pre>
should only list standard directory names.
<br><br><li>
Test the packaging.
After the port installs correctly issue the command
<code>make package</code> to create a package. To test the
package first do a <code>pkg_delete</code> and then do a
<code>pkg_add</code> The results after an add should EXACTLY
match the results after a `make install'.
<br><br><li>
Mail <a href="mailto:ports@openbsd.org">ports@openbsd.org</a> with a short
note asking for comments and testing. Attach the port to this email and
send it out.
<p>
Try to get others to test it on a variety of platforms for you.
<ul><li>
The DEC Alpha is good because it has only static libraries and because
<code>sizeof(int) != sizeof(long)</code>.
<li>
Sun SPARC is good because it is very common and because its byte order is
the reverse of i386; if you developed on SPARC, of course, you'd want it
tested on i386.
</ul>
<br><li>
Incorporate any feedback you get. Test it again on your platform.
Get those who gave you feedback to test it again from your new port.
<br><br><li>
Finally, include it in the "ports" tree.
If you do not have CVS access, ask someone on
<a href="mailto:ports@openbsd.org">ports@openbsd.org</a> to commit it.
<br><br><li>
If you are a developer with CVS access, check it in.
We normally use "import" for a new port,
rather than adding a zillion (or a dozen) files individually.
Import uses "vendor branch" version numbers like 1.1.1.1, but don't worry
about that! :-) If you make changes to a specific file (edit, then
cvs commit), it will be 1.2, and that will be used.
<p>
In short, import is typically used when a port is created.
From that point on cvs add and cvs rm are typically used to add or remove
files, and the normal edit->commit cycle for changes.
You might use something like this:
<pre>
$ cd kaffe1
$ make clean # you really don't want to check in all of work!
$ cvs -d cvs.openbsd.org:/cvs import -m 'kaffe port' ports/lang/kaffe1 \
<I>YourName</I> <I>YourName_YYYY-MMM-DD</I>
</pre>
<ul><li>
-d cvs.openbsd.org:/cvs says where cvs lives. This can be omitted if you
have a CVSROOT environment variable defined.
<li>
-m 'kaffe port' is your login message. Change it to whatever you like
<li>
ports/lang/kaffe1 is the path relative to /cvs where the port lives
<li>
<i>YourName</i> (replaced with your login name) is the 'vendor tag'.
You imported it so you are the vendor.
<li>
<i>YourName_YYYY-MMM-DD</i> (e.g., ian_2000-Jan-01)
is the 'vendor release tag'. This is as good as any.
</ul>
<br>
As a real example, here is the output of checking in the Kaffe1 port,
which one of us did on September 8, 1998:
<pre>
$ cd kaffe1
$ make clean >/dev/null
$ cvs import -m 'kaffe1.0(==JDK1.1) port' ports/lang/kaffe1 ian ian_1998-Sep-08
ian@cvs.openbsd.org's password: (not shown, obviously)
I ports/lang/kaffe1/CVS
I ports/lang/kaffe1/files/CVS
I ports/lang/kaffe1/pkg/CVS
N ports/lang/kaffe1/Makefile
cvs server: Importing /cvs/ports/lang/kaffe1/files
N ports/lang/kaffe1/files/md5
cvs server: Importing /cvs/ports/lang/kaffe1/pkg
N ports/lang/kaffe1/pkg/COMMENT
N ports/lang/kaffe1/pkg/DESCR
N ports/lang/kaffe1/pkg/PLIST
No conflicts created by this import
$
</pre>
<li>
Last but not least, add a one-line entry for the new port
in its parent directory's Makefile, e.g., for ports/lang/kaffe1,
add it to ports/lang/Makefile.
<br><br><li>
Maintain the port! As time goes by, problems may arise, or new versions
of the software may be released. You should strive to keep your port up
to date. In other words - iterate, test, test, iterate...
<br><br><li>
When updating a port, remember to handle dependencies! You shouldn't break any
port that depends on yours. In case of problems, communicate with the
maintainers of such ports. Likewise, be alert for dependency updates, and
check that the maintainer did their job.
</ol>
Thank you for supporting the OpenBSD "ports" process!
<hr>
<a href="porting.html"><img height=24 width=24 src="back.gif"
border=0 alt="Porting"></a>
<a href="mailto:www@openbsd.org">www@openbsd.org</a>
<br><small>$OpenBSD: checklist.html,v 1.55 2004/01/02 02:51:54 jose Exp $</small>
</body>
</html>
![[BACK]](/icons/back.gif){kind=icon}
Return to checklist.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / www