Difference between revisions of "Create a package (tarball) for distribution"

From NAS-Central Buffalo - The Linkstation Wiki
Jump to: navigation, search
Line 1: Line 1:
 
{{Template:Articles}}This article assumes you want to download and build some software from the software's source code. It further assumes the source code is available as some ''tar'' file (a [[w:tar ball|tar ball]]) and that the software source follows a common structure and comes with a common mechanism to build it.
 
{{Template:Articles}}This article assumes you want to download and build some software from the software's source code. It further assumes the source code is available as some ''tar'' file (a [[w:tar ball|tar ball]]) and that the software source follows a common structure and comes with a common mechanism to build it.
  
Since there are many, many different software packages out there, there is no guarantee that the particular package can be build exactly as described here. There is no guarantee that it is packed as a tar file, and there is no guarantee that you have everything to build it. That's why many packages come with '''d-o-c-u-m-e-n-t-a-t-i-o-n'''! It might sound shocking, but it is a clever idea to read that one first. Often the documentation also explains what additional tools and libraries are needed to build the software, and how to fine-tune the build.
+
That common structure needs to be a ''GNU build system'', starting with
 +
* a <code>configure</code> script, made with
 +
* GNU <code>autoconf</code> and using
 +
* GNU <code>automake</code> and
 +
* GNU <code>libtool</code>.
  
The remainder of this article further assumes
+
Further the source code author must have used <code>autoconf</code>, <code>automake</code> correctly and in compliance with the GNU coding standards by keeping directory output variables in the <code>Makefile</code>s unexpanded. This allows to use <code>make install</code> and overriding install locations. A feature which is used later in this description to prepare for packaging.
  
* The source code comes with a <tt>configure</tt> script
+
Since there are many, many different software packages out there, there is no guarantee that the particular package can be build exactly as described here. There is no guarantee that it is packed as a tar file, and there is no guarantee that you have everything to build it. That's why many packages come with '''documentation'''! It might sound shocking, but it is a clever idea to read that one first. Often the documentation also explains what additional tools and libraries are needed to build the software, and how to fine-tune the build.
* You have all the common development tools installed
+
  
'''1)''' Download the source to the preferred place:
+
The remainder of this article further assumes you have all the common development tools installed
 +
 
 +
'''1)''' Download the source to a preferred place:
  
 
  mkdir -p <compiling-folder> #I suggest to create a folder on /dev/hda3.../mnt/ on ppc-LS, /mnt/hda/ on the LS2
 
  mkdir -p <compiling-folder> #I suggest to create a folder on /dev/hda3.../mnt/ on ppc-LS, /mnt/hda/ on the LS2
Line 15: Line 20:
  
 
'''2)''' Untar the package - use xzvf if it has a tar.gz-extension (=.tgz) and xjvf if it has tar.bz2
 
'''2)''' Untar the package - use xzvf if it has a tar.gz-extension (=.tgz) and xjvf if it has tar.bz2
  tar xzvf <app-source>.tar.gz
+
tar xzvf <app-source>.tar.gz
 
'''3)''' change into the new directory
 
'''3)''' change into the new directory
  cd <app-source>
+
cd <app-source>
'''4)''' create the folder-structure for the Package we want to create
+
  mkdir -p PACKAGE/usr/local/
+
'''5)''' check which options are available for ./configure by executing
+
  ./configure --help
+
'''6)''' configure the app with the right prefix
+
  ./configure --prefix=<path2this_folder>/PACKAGE/usr/local --sysconfdir=/etc <additional optional options>
+
'''7)''' compile the app
+
  make
+
'''8)''' install the compiled app afterwards
+
  make install
+
'''9)''' change into the PACKAGE-folder
+
  cd PACKAGE
+
'''10)''' Optional: create a folder which contains all the packages
+
  mkdir <compiling-folder>/PACKAGES
+
'''11)''' tar the file-structure up into a nice package
+
  tar zvcf /<compiling-folder>/PACKAGES/<appname>_<architecure>.tar.gz
+
where architecure is ppc for LS1, HG & HS and mips for the LS2
+
  
 +
'''4)''' check which options are available for ./configure by executing
 +
./configure --help
 +
'''5)''' configure the application with the right prefix for the final destination (e.g. <tt>/usr/local</tt>), and '''not''' for your local temporary installation directory <tt>PACKAGE/usr/local</tt>. If you cross-compile you also need to point to the cross compiler, linker, assembler.
 +
./configure --prefix=/usr/local CC=... ...
 +
'''6)''' compile, but don't install the application
 +
make
 +
'''7)''' Become root
 +
su
 +
'''8)''' Clean and prepare the temporary installation directory structure to which the package will be temporarily installed before it is packed. This cleanup ensures that no left-overs from previous build attempts or accidentally moved files will be packaged, too. '''Warning:''' If you do this on the wrong directory, you might accidentally delete your whole Linux system ...
 +
rm -rf PACKAGE # '''DANGER''' Don't do this withe the wrong directory!
 +
# Create temporary version of the ''prefix'' directory
 +
mkdir -p PACKAGE/usr/local
 +
'''9)''' Install the compiled application afterwards to your temporary packaging directory, temporarily overriding the prefix setting for the installation only. This must not trigger a recompilation, and it won't if the software author has created the configure system correctly. It should keep path information already compiled into the application and related files. That is, the application should contain the final destination pathes, as set with <code>--prefix=...</code> with <code>configure</code>, while only the installation is redirected to our temporary packaging directory.
 +
make install prefix=PACKAGE/usr/local
 +
'''10)''' Continue as root, package the data up.<br>
 +
'''10a)'''  For example, tar the file-structure up into a nice package
 +
tar cvfz <appname>_<architecture>.tar.gz -C PACKAGE
 +
where architecture is ppc for LS1, HG & HS and mips for the LS2
  
'''you should now have a freshly compiled package in /<compiling-folder>/PACKAGES which is perfect for distribution or later for the creation of [[ipkg]]-packages!'''
+
'''10b)''' Or build an [[ipkg]] package. The following is only a rough sketch, check the ipkg documentation for details
 +
ipkg-proto PACKAGE  # creates an initial prototype file
 +
# edit prototype file
 +
# create CONTROL files
 +
# add entries for CONTROL files to prototype file
 +
ipkg-mk -c  # build the package
  
 +
Scripting some of the above steps might make sense, instead of typing the same commands again and again.
 +
<!--
 
----
 
----
 
No, you have a package which often has pathes compiled into it. And since you have pointed the --prefix to some local path you probably have a package which can't be installed anywhere else than on <tt><some strange path>/PACKAGE/usr/local</tt> while you really want it to be working in <tt>/usr/local</tt>. Examples are applications which compile the path to their help files, shared libs, config files, etc. into themself, taking the data from configure.
 
No, you have a package which often has pathes compiled into it. And since you have pointed the --prefix to some local path you probably have a package which can't be installed anywhere else than on <tt><some strange path>/PACKAGE/usr/local</tt> while you really want it to be working in <tt>/usr/local</tt>. Examples are applications which compile the path to their help files, shared libs, config files, etc. into themself, taking the data from configure.
Line 44: Line 57:
 
Then tell us how to create perfect packages. You seem to know it, so why don`t you share your knowledge?
 
Then tell us how to create perfect packages. You seem to know it, so why don`t you share your knowledge?
 
[[User:Mindbender|Mindbender]] 20:41, 19 July 2006 (EDT)
 
[[User:Mindbender|Mindbender]] 20:41, 19 July 2006 (EDT)
 
+
-->
 
[[Category:Development]]
 
[[Category:Development]]

Revision as of 22:27, 22 February 2007

This article assumes you want to download and build some software from the software's source code. It further assumes the source code is available as some tar file (a tar ball) and that the software source follows a common structure and comes with a common mechanism to build it.

That common structure needs to be a GNU build system, starting with

  • a configure script, made with
  • GNU autoconf and using
  • GNU automake and
  • GNU libtool.

Further the source code author must have used autoconf, automake correctly and in compliance with the GNU coding standards by keeping directory output variables in the Makefiles unexpanded. This allows to use make install and overriding install locations. A feature which is used later in this description to prepare for packaging.

Since there are many, many different software packages out there, there is no guarantee that the particular package can be build exactly as described here. There is no guarantee that it is packed as a tar file, and there is no guarantee that you have everything to build it. That's why many packages come with documentation! It might sound shocking, but it is a clever idea to read that one first. Often the documentation also explains what additional tools and libraries are needed to build the software, and how to fine-tune the build.

The remainder of this article further assumes you have all the common development tools installed

1) Download the source to a preferred place:

mkdir -p <compiling-folder> #I suggest to create a folder on /dev/hda3.../mnt/ on ppc-LS, /mnt/hda/ on the LS2
cd <compiling-folder>    
wget http://<download-location>/<app-source>

2) Untar the package - use xzvf if it has a tar.gz-extension (=.tgz) and xjvf if it has tar.bz2

tar xzvf <app-source>.tar.gz

3) change into the new directory

cd <app-source>

4) check which options are available for ./configure by executing

./configure --help

5) configure the application with the right prefix for the final destination (e.g. /usr/local), and not for your local temporary installation directory PACKAGE/usr/local. If you cross-compile you also need to point to the cross compiler, linker, assembler.

./configure --prefix=/usr/local CC=... ...

6) compile, but don't install the application

make

7) Become root

su

8) Clean and prepare the temporary installation directory structure to which the package will be temporarily installed before it is packed. This cleanup ensures that no left-overs from previous build attempts or accidentally moved files will be packaged, too. Warning: If you do this on the wrong directory, you might accidentally delete your whole Linux system ...

rm -rf PACKAGE # DANGER Don't do this withe the wrong directory!
# Create temporary version of the prefix directory
mkdir -p PACKAGE/usr/local

9) Install the compiled application afterwards to your temporary packaging directory, temporarily overriding the prefix setting for the installation only. This must not trigger a recompilation, and it won't if the software author has created the configure system correctly. It should keep path information already compiled into the application and related files. That is, the application should contain the final destination pathes, as set with --prefix=... with configure, while only the installation is redirected to our temporary packaging directory.

make install prefix=PACKAGE/usr/local

10) Continue as root, package the data up.
10a) For example, tar the file-structure up into a nice package

tar cvfz <appname>_<architecture>.tar.gz -C PACKAGE

where architecture is ppc for LS1, HG & HS and mips for the LS2

10b) Or build an ipkg package. The following is only a rough sketch, check the ipkg documentation for details

ipkg-proto PACKAGE  # creates an initial prototype file
# edit prototype file
# create CONTROL files
# add entries for CONTROL files to prototype file
ipkg-mk -c  # build the package

Scripting some of the above steps might make sense, instead of typing the same commands again and again.