Building ipkgs

From: Carl Worth <cworth_at_east.isi.edu>
Date: Fri, 25 May 2001 14:48:10 -0400

Mark Trinidad writes:
> >Mark Trinidad writes:
> > > Is it possible to build ipkgs without a Debian Linux system?
> > > How do I do that? Jim tells me you are going to update the
> > > website on this.

OK, the new ipkg-build script that I just committed to handhelds.org
CVS will create an ipkg without any need for dpkg-deb. You can find it
in the familiar/dist/ipkg/util module from handhelds.org CVS (see
http://www.handhelds.org/sources.html). If you are too lazy to check
this module out from CVS then you may grab it from the following ugly
URL:

http://cvs.handhelds.org/cgi-bin/viewcvs.cgi/~checkout~/familiar/dist/ipkg/util/ipkg-build?rev=1.3&content-type=text/plain

Here's the mini-HOWTO:

1) Create the directory structure and files you want to appear on the
   iPAQ.

2) Create a directory named CONTROL at the top-level of this directory
   structure.

3) Inside CONTROL create a file named "control" with lines of the form
   "Field: value". Required fields are Package, Version, Architecture,
   Maintainer, and Description. Optional fields include Priority,
   Section, and Depends. The meaning of each of the fields will be
   given later in this document.

4) If your package has any configuration files, then create a file
   CONTROL/conffiles which lists the absolute path of each
   configuration file, (as it will appear on the installed system),
   one per line. This will prevent the package management system from
   automatically overwriting configuration changes when the user
   upgrades the package.

5) If needed your package may include some scripts that will be
   invoked by the package maintenance system. There are four possible
   times a script will be run: just before your package is installed,
   just after your package is installed, just before the package is
   removed, and just after the package is removed. These scripts are
   named preinst, postinst, prerm, and postrm and should be located in
   the CONTROL directory. The scripts should return 0 on success, (a
   non-zero return value from preinst will prevent your package from
   being installed -- this can be useful in rare situations). The
   scripts can assume a tty is available so they may prompt the user.

6) Now simply run:

        ipkg-build directory [destination_directory]

   where directory is the directory you have created. The
   destination_directory is optional and defaults to the current
   directory. The ipkg-build script performs several sanity checks on
   the package directory and should guide you through any problems.

Here is an example control file which you may use as a template:

### Begin CONTROL/control example
Package: foo
Priority: optional
Version: 0.0
Architecture: arm
Maintainer: Familiar User <user_at_somehost.net>
Depends: libc6, grep
Description: foo is the ever-present example program -- it does everything
 foo is not a real package. This is simply an example that you
 may modify if you wish.
 .
 When you modify this example, be sure to change the Package, Version,
 Maintainer, Depends, and Description fields.
### End CONTROL/control example

The meaning of the various fields in CONTROL/control is as follows:

   Package is the name of the package and should match the regular
   expression [a-z0-9.+-]\+

   Version should have at least one digit and should match
   [a-zA-Z0-9.+]*. Version may also contain an optional trailing
   revision matching "-fam[0-9]\+". This revision should be
   incremented each time the package changes but the version does not,
   (ie. a packaging tweak). It may be reset, (or simply omitted), each
   time the version is incremented.

   Architecture should specify the architecture for which the package
   is compiled. Valid values for Familiar currently include "arm" and
   "all".

   Maintainer should be the name and email address of the person
   responsible for maintaining the package, (not necessarily the
   author of the program).

   Description should be a short, (less than 80 characters)
   description of the program. It may also include a long description
   on subsequent lines, (each indented by a single space
   character). Blank lines in the long description may be indicated by
   a line consisting of a space character followed by a period, ie "
   ."

   Priority should be one of: required, standard, important, optional,
   or extra. Most programs should use optional.

   Section can be one of the following: admin, base, comm, editors,
   extras, graphics, libs, misc, net, text, web, x11.

   Depends indicates packages which must also be installed in order
   for this package to work. The packages should be listed on a
   single line, separated by commas.

Have fun,

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth_at_east.isi.edu
4350 N. Fairfax Dr. #770, Arlington VA 22203	          703-812-3725
Received on Fri May 25 2001 - 11:47:35 EDT

This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:12:25 EDT