I used the work flow found on this link http://developers.sun.com/solaris/articles/gnu.html. Still trying to figure it out.
This is a more workable and easier to follow one. http://autotoolset.sourceforge.net/tutorial.html#SEC39
There are two types of Debian packages.
The naming convention of the Debian package is as following line:
<pack-name>_<VersionNumber>-<revistion>_<DebianArchitecture>.deb
Dependencies are stored in the “control” file. This file also includes other information of the package, package name, priority, version and so on. And there are different levels of dependencies:
| A | Dependency | B | Description |
|---|---|---|---|
| Depends | A will not work without B | ||
| recommend | A goes well with existence of B | ||
| suggests | B enhance A | ||
| conflicts | (A&B')or(A'&B) | ||
| replaces | A has update of B | ||
| provides | B use output from A as input, mostly | ||
| pre-depends | B will not install even not be able to be extracted before A, this is a special relationship. |
conffile is a list of configuration files which the package management system will not overwrite during installation or upgrade.
User can also define “want” flag on packages and virtual packages.
I am not 100% sure if the package management system is using the GNU build tool. However, I think it is. If you download a source package from the repository, you can compile it using the package compiling tool which seems to be using the GNU auto tools as the lower layer tool. Just check the dpkg with –version.
OpenSUSE uses a different package management system based on the RPM file format. RPM is the packaging system created by Red Hat and standardized by the LSB. Opensuse use it through yast or zypper as the package manager.
One major difference between rpm and deb formats is that rpm uses only “control file” called a specfile. This file contains all the necessary information in order to build the package. The macros in this specfile will be converted into make commands during the build procedure. Dependencies are checked at the building time.
The dependency check is taken care in the similar way to dpkg. A dependency tree will be built.
I downloaded warboat from sourceforge, compiled, and working. Binary package created. It is installed on the lab server ekans.studlab.os3.nl:/usr/bin/warboats.a
Control file
Package: warboats Version: 1.1-1 Section: base Priority: optional Architecture: all Depends: bash (>= 2.05a-11), coreutils (>= 5.0-5) Maintainer: A B <A@B.C> Description: A funny board game
build package HOWTO
binutils for multi architecture
explain the local package
I downloaded the warboat source code from the internet. It does not come with a package. I used gcc to compile it. And created folder “debian” to accommodate the executable file created by gcc. It is warboat.a.
folder strcture
debian -> DEBIAN -> control
-> usr -> bin -> warboat.a
So the game will be installed in /usr/bin on target machine. And my control file was shown above. Then use dpkg-deb to build the local package.
output of the game:
Your Grid Your Board 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 A ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ A ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ C ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ C ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ D ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ D ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ E ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ E ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ F ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ F ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ G ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ G ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ H ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ H ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ I ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ I ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ J ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ J ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ C/c = Carrier B/b = Battleship D/d = Destroyer S/s = Submarine P/p = PT Boat X = Miss Lowercase indicates a "hit" portion of the ship Where should your Carrier be (RowColumnDirection [A-J][1-10][NSEW])?
cross compiling GCC and cross compile I tried to use gcc to cross compile the program. The package itself seems to be working on the target machine, intel based macbook. So I can install the package on the macbook, but the installed program does not work.