Play with GNU autotools
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
Assignment Debian
Types of Debian packages
There are two types of Debian packages.
- Binary
- Binary package contains: executable files, configuration files, man page, copyright and others files
- Source
- A .dsc - description of the package and all the file names contained in the package
- A .orig.gz - original and raw (non-specific) source files
- A diff.gz - Debian specific source ?? Adapted to best fit into Debian system?
Naming convention
The naming convention of the Debian package is as following line:
<pack-name>_<VersionNumber>-<revistion>_<DebianArchitecture>.deb
- Package name: is the name of the software project or main application.
- Version Number: is the current version number, but it is up to the developer what kind of number they are going to use.
- revision: Revision number. Can also be used to indicate minor update? [yes]..
- Architecture: platform on which the package is designed for.
Handling dependency
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.
- unknow - not set before
- install - want to have it installed or be able to upgrade
- remove - remove the package and preserve the configuration file
- purge - remove everything
- hold - keep the current status of the package, useful when user wants to stay with certain version of the software
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.
Assignment OpenSUSE
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.
Download and compile a game
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.