File: [local] / www / Attic / checklist.html (download) (as text)
Revision 1.22, Sat Mar 11 18:49:19 2000 UTC (24 years, 2 months ago) by rohee
Branch: MAIN
Changes since 1.21: +39 -38 lines
HTML cleanup
HTML4 recommands replacing empty <p> with <br> or <br><br>
it looks the same in Netscape and is more standard compliant
|
<!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-2000 by OpenBSD.">
<title>OpenBSD Porting Checklist</title>
</head>
<body text=Black bgcolor=White link="#23238E">
<img height=30 width=141 src=images/smalltitle.gif alt="[OpenBSD]" >
<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 not totally accurate nor perfect.
Direct comments and questions to <a href="mailto:turan@openbsd.org">
turan@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 here. They can often give you
good advice or test ports for you.
</ul>
<br><li>
Check out a copy of the ports tree from cvs.
You can find instructions 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>.
<ul><li>
Create the directories <code>files, patches, pkg</code>.
<li>
Create these empty files <code>pkg/COMMENT, pkg/DESCR, pkg/PLIST</code>
</ul>
<br><li>
Add the fetch portions of the Makefile.
<ul><li>
Fill in EXTRACT_SUFFIX if its 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_SITE}${DISTNAME}$EXTRACT_SUFFIX}. All three are used. Don't
set DISTNAME to point to the file directly.
<li>
You can check to see if you have filled this 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/template/network.conf.template.
Set MASTER_SITES to ${MASTER_SITE_GNU}, or ${MASTER_SITE_SUNSITE}, etc.
To simplify this process, the construct %SUBDIR% is replaced by the variable
MASTER_SITE_SUBDIR in your Makefile.
<li>
Ports normally correspond to given versions of software. Once they are retrieved, files are checksummed and compared to the recorded
checksum in files/md5. 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>files/md5</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, its <i>work/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 redistribution 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 GNU_CONFIGURE or HAS_CONFIGURE 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 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, 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.
<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>diff -p -u</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>
Add a small explanation of the patch role in the patchfile before
the patch itself, and an OpenBSD CVS tag <code>$OpenBSD$</code>.
<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><br>
<ul><li>
If the port can build with object files outside its source tree,
this is cleaner (many programs using <code>GNU_CONFIGURE</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
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
<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
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 no longer 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
SEPARATE_BUILD=concurrent: 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 meet with problems, as some
source files may be regenerated at awkward moments.
<br><br><li>
Edit <i>pkg/DESCR</i>, <i>pkg/COMMENT</i>, <i>pkg/PLIST</i>.
<ul>
<li>
COMMENT is a <strong>SHORT</strong> one-line description of the port
(max. 60 characters). Do NOT include the package name (or version number
of the software) in the comment. Do NOT start with an uppercase letter
unless semantically significant, do NOT end with a period.
<li>
DESCR is a longer description of the port. One to a few paragraphs
concisely explaining what the port does is sufficient.
<li>
PLIST is kept empty at this point.
</ul>
<br><li>
Install the application with <b>make install</b>
<p>
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.
<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-auto 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-auto' 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>
Move `PLIST-auto' to `PLIST'
<p>
Ports that install shared libraries will need two versions of the PLIST file.
<ul>
<li>
PLIST describes the files installed on those architectures that support
shared libraries.
<li>
PLIST.noshared describes the files installed on architectures that do not
support shared libs.
<li>
Typically, PLIST.noshared is a copy of PLIST less references to any
shared libraries.
</ul>
<br><li>
Keep repeating uninstall and reinstall until perfect.<br>
<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
<p><code>find /usr/local -newer work/.install_started -print</code>
<p>should only list standard directory names.
<br><br><li>
Test the packaging:<br>
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
sent it out. If you don't get any comments, send email to
<a href="turan@openbsd.org">turan@openbsd.org</a> and I will pick it for you.
<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.
<p>
If you do not have CVS access, ask someone on
<a href="ports@openbsd.org">ports@openbsd.org</a> to commit it. Don't forget
about me, <a href="turan@openbsd.org">turan@openbsd.org</a> if no one
picks it up.
<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 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>
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, i.e., 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...
</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.22 2000/03/11 18:49:19 rohee 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