OpenBSD Porting Checklist

atyu30

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
ports@openbsd.org.

If you want to be a maintainer, subscribe to
ports@openbsd.org.

• 
  This is where all ports discussions take place.  
  
• 
  Reading this list is important since many announcements go over this list.
  
• 
  You will find a lot of porting-savvy people there.  They can often give you
  good advice or test ports for you.
  

Being a maintainer means more than just submitting ports.
It also means trying to keep them up-to-date, and to answer questions about
them.

Check out a copy of the ports tree from cvs.
You can find instructions on how to do this at the
anonymous cvs page
.

Pick a place to put your port and create the basic
infrastructure there.  Use the template Makefile at
/usr/ports/infrastructure/templates/Makefile.template.  
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.

• 
  Create the directory pkg.
  
• 
  Create the empty files pkg/DESCR, pkg/PLIST.
  

Add the fetch portions of the Makefile.  

• 
  Fill in EXTRACT_SUFX if it's anything besides .tar.gz.  Other examples are
  .tar.Z, or .tgz.
  
• 
  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.
  
• 
  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/.
  Don't forget the trailing slash.
  Try to have at least three distinct sites as well.
  Place the most easily accessible first as they are traversed in order.
  
• 
  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.
  
• 
  You can check to see if you have filled these values in correctly by typing
  make fetch-all.
  

For more complex ports, you have more options and tools available to you:

• 
  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.
  
• 
  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.
  
• 
  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.
• 
  If a given port needs more than about 5 DISTFILES + PATCHFILES to work, use DIST_SUBDIR to avoid cluttering
  /usr/ports/distfiles too much.
  
• 
  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.
• 
  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.
  
• 
  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.

Create a checksum in distinfo by typing make makesum.
Then verify the checksum is correct by typing make checksum.

• 
  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.
• 
  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).
• 
  Patches that need specific treatment should be mentioned in DISTFILES, and removed from EXTRACT_ONLY, for historic reasons.
  

Extract the port with make extract.  Pay attention to where the base
of the sources are.  Usually, it's w-${PKGNAME}${FLAVOR_EXT}/${DISTNAME}. You may need to
modify the Makefile's WRKDIST variable if it is different.

Read the installation documentation and note what you have to do to build
the port and any special options that might be needed.

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.

• 
  PERMIT_PACKAGE_CDROM tells us if we can put the package on the cdrom.
  
• 
  PERMIT_PACKAGE_FTP tells us if we can put the package on the ftp sites.
  
• 
  PERMIT_DISTFILES_CDROM tells us if we can mirror the distfiles on the cdrom.
  
• 
  PERMIT_DISTFILES_FTP tells us if we can mirror the distfiles on the ftp sites.
  

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
/usr/local/share/doc//.
In addition to the PERMIT_* values, put a license marker like
# License above them as a comment, this way we know why
the PERMIT_* values are set the way they are.

Add configuration options to Makefile and/or create the configuration script.

• 
  You can add a port configuration script named `configure' to a directory
  named scripts/. This will be run before any configuration
  specified by CONFIGURE_STYLE is run.
  
• 
  If GNU configure is used you may want to run ./configure --help
  to see what options are available.  
  
• 
  Anything that you may want to override can be changed by adding the
  --option flags to the CONFIGURE_ARGS parameter in the Makefile.  
  
• 
  Use CONFIGURE_ARGS+= to append to the variable.  CONFIGURE_ARGS= will
  overwrite it.
  

Try building the port with make build.  

• 
  If you're lucky, the port will go all the way through without errors.  
  
• 
  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.  
  
• 
  Patches must be relative to ${WRKDIST}.  
  
• The easiest way to reset the port and test your patches is
  make clean patch. This will delete the work directory, re-extract,
  and patch your port.
  

Begin a cycle of make build, generate a patch (or use make
update-patches), and
make clean patch.

• 
  Patches go in the directory patches/ 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.
  (make update-patches does this automatically for you.)
  
• 
  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.
  
• 
  Only patch one source file per patchfile, please.
  
• 
  Use make update-patches to generate patches.
  
• 
  All patches MUST be relative to ${WRKDIST}.
  
• 
  Check that patches DON'T 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.
  
• 
  Write a small explanation at the beginning of the patchfile about its purpose
  (not mandatory).
  
• 
  Please feed your patches back to the author of that piece of software.
  

Try setting SEPARATE_BUILD.

• 
  If the port can build with object files outside its source tree,
  this is cleaner (many programs using CONFIGURE_STYLE=gnu can),
  and may help people who mount their ports tree on several arches.
  
• 
  This can also spare you some effort, as you will possibly be able to
  restart the cycle at configure most of the time.
  

Peruse the output (if any) and tweak any options in the Makefile.
To repeat issue the command `make clean configure'.
Note: make sure host-dependent files go in /etc or
/etc/, but NEVER REPLACE OR MODIFY
existing files in /etc.  Best to have install place them
in /usr/local/share/ and then copy to
/etc or /etc/ 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 /usr/local is included in the PLIST.
After a package has been installed the contents of pkg/MESSAGE
will be displayed if it exists.
The OpenBSD file locations are:
   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/
   installed include files:                /usr/local/include or
                                        /usr/local/include/
   single-machine data:                        /etc or /etc/
   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/
   misc documentation:                        /usr/local/share/doc/
   examples files:                        /usr/local/share/examples/

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.

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 make patch.
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 SEPARATE_BUILD=simple -- building on
distinct arches simultaneously may be met with problems, as some
source files may be regenerated at awkward moments.

Add COMMENT in Makefile.
COMMENT is a SHORT 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, and
do NOT end with a period.
DON'T EVER START WITH AN INDEFINITE ARTICLE SUCH AS `a' or `an';
remove the article altogether.

Edit pkg/DESCR, pkg/PLIST.

• 
  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'.
  
• 
  PLIST is kept empty at this point.
  

If the application needs to create a user or a group, choose the lowest free
id from /usr/ports/infrastructure/db/user.list for your port to
use and make sure your port gets added to this file at commit time.

Install the application with make install.
If the port installs dynamic libraries, check their symbol tables
with nm, as some mistaken software strips dynamic libraries,
which may lead to weird failures later. On the other hand, executable binaries
SHOULD be stripped; file 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.

Check port for security holes again. This is
especially important for network and setuid programs. See
our security recommendations
for that. Log interesting stuff and fixes in the
pkg/SECURITY 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:

      $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.

Create pkg/PLIST.  After the install is complete use the developer's command,
make plist which makes the file PLIST in the pkg directory.
This file is a candidate packing list.  
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.
Ports that install shared libraries will have another file called PFRAG.shared.

• 
  PLIST describes the files being independent of whether the architecture supports shared libraries or not.
  
• 
  PFRAG.shared describes only the files being additionally installed on those architectures that support
  shared libraries.
  
• 
  PFRAG.noshared describes only the files being additionally installed on architectures that do not
  support shared libraries.
  

Test the packaging.
After the port installs correctly issue the command
make package to create a package.  To test the
package first do a pkg_add and then do a
pkg_delete   

Verify dependencies. Peruse your logs to verify the port did detect what is
mentioned in DEPENDS, and nothing more. Check names for hidden dependencies
(stuff that exists elsewhere in the ports tree and might be detected if the
user installs some other ports first).

Verify shared library dependencies. Run make lib-depends-check
and add every LIB_DEPENDS or WANTLIB annotation
that is needed until it runs cleanly (run make clean=package
to remove the old package after updating the port's Makefile).
You may want to read
the update guidelines
to understand why this is so important.

Check for regression tests, and whether they run cleanly. Set
NO_REGRESS=Yes if a port has no test infrastructure.
Please note: do not set NO_REGRESS if a port has an empty
regression infrastructure.

Mail
ports@openbsd.org
with a short
note asking for comments and testing.  Make sure to attach the port/patch to
this email and send it out (mailinglist archives just contain the mails itself).
Try to get others to test it on a variety of platforms for you.

• 
  The AMD64 Opteron systems are good because they are fast, and because
  sizeof(int) != sizeof(long) on this platform.
  
• 
  Sun SPARC and UltraSPARC are good because they are very common and because
  their byte order is the opposite of i386; if you developed on SPARC, of course,
  you'd want it tested on i386.
  

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.

Finally, include it in the "ports" tree.
If you do not have CVS access, ask someone on
ports@openbsd.org
to commit it.  

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.
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:
$ 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 \
        YourName YourName_YYYY-MMM-DD

• 
  -d cvs.openbsd.org:/cvs says where cvs lives. This can be omitted if you
  have a CVSROOT environment variable defined.
  
• 
  -m 'kaffe port' is your login message.  Change it to whatever you like
  
• 
  ports/lang/kaffe1 is the path relative to /cvs where the port lives
  
• 
  YourName (replaced with your login name) is the 'vendor tag'.
  You imported it so you are the vendor.
  
• 
  YourName_YYYY-MMM-DD (e.g., ian_2000-Jan-01)
  is the 'vendor release tag'.  This is as good as any.
  

As a real example, here is the output of checking in the Kaffe1 port,
which one of us did on September 8, 1998:
$ 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
$

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.

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...

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.

Thank you for supporting the OpenBSD "ports" process!
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/28922/showart_314612.html