Create a package (tarball) for distribution - Revision history

Ramuk: /* Building Non-''GNU build system'' Software */

Ramuk — Wed, 12 Sep 2007 05:30:03 GMT

Building Non-''GNU build system'' Software

← Older revision		Revision as of 05:30, 12 September 2007
Line 74:		Line 74:
	make install		make install
	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>. This is because the package may contain files with hard-coded paths. In order to fix this problem these files must be replaced by the corresponding files of your previous real installation. pack_sync tool may be used for this purpose:		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>. This is because the package may contain files with hard-coded paths. In order to fix this problem these files must be replaced by the corresponding files of your previous real installation. pack_sync tool may be used for this purpose:
-	wget http://downloads.nas-central.org/~~uploads~~/mktarball/pack_sync	+	wget http://downloads.nas-central.org/Uploads/OldUploads/mktarball/pack_sync
	./pack_sync PACKAGE		./pack_sync PACKAGE
	If you are really using 'PACKAGE' you may omitt this (default parameter).		If you are really using 'PACKAGE' you may omitt this (default parameter).

Jonli447 at 03:06, 11 September 2007

Jonli447 — Tue, 11 Sep 2007 03:06:01 GMT

← Older revision		Revision as of 03:06, 11 September 2007
Line 74:		Line 74:
	make install		make install
	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>. This is because the package may contain files with hard-coded paths. In order to fix this problem these files must be replaced by the corresponding files of your previous real installation. pack_sync tool may be used for this purpose:		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>. This is because the package may contain files with hard-coded paths. In order to fix this problem these files must be replaced by the corresponding files of your previous real installation. pack_sync tool may be used for this purpose:
-	wget http://downloads.~~linkstationwiki~~.~~net~~/uploads/mktarball/pack_sync	+	wget http://downloads.nas-central.org/uploads/mktarball/pack_sync
	./pack_sync PACKAGE		./pack_sync PACKAGE
	If you are really using 'PACKAGE' you may omitt this (default parameter).		If you are really using 'PACKAGE' you may omitt this (default parameter).

Ramuk: /* Overview */

Ramuk — Tue, 17 Jul 2007 03:50:41 GMT

Overview

← Older revision		Revision as of 03:50, 17 July 2007
Line 91:		Line 91:

	=== Overview ===		=== Overview ===
-	After the software has finally been build (see the previous chapters), one can now wrap the stuff up in a package for distribution. A simple package would be a [[tar]] file, a more convenient package would be an [[ipkg]] package. The following sections describe both alternatives.	+	After the software has finally been build (see the previous chapters), one can now wrap the stuff up in a package for distribution. A simple package would be a tar file, a more convenient package would be an [[ipkg]] package. The following sections describe both alternatives.

	Scripting the build as described above, and the packaging might make sense, instead of typing the same commands again and again.		Scripting the build as described above, and the packaging might make sense, instead of typing the same commands again and again.

77.128.157.40: /* Building ''GNU build system'' based Software */

77.128.157.40 — Sat, 10 Mar 2007 10:43:10 GMT

Building ''GNU build system'' based Software

← Older revision		Revision as of 10:43, 10 March 2007
Line 10:		Line 10:
	== Building ''GNU build system'' based Software ==		== Building ''GNU build system'' based Software ==

-	Many, but not all free software is build as, or structured in a similar way, to what the FSF established as the ''GNU build system''. The most apparent hint, but not an absolute proof, is the existence of an ~~<code>configure</code>~~ script which is supposed to be run to configure the build system for the current platform.	+	Many, but not all free software is build as, or structured in a similar way, to what the FSF established as the ''GNU build system''. The most apparent hint, but not an absolute proof, is the existence of an '''onfigure''' script which is supposed to be run to configure the build system for the current platform.

-	For a ''GNU build system'' the ~~<code>~~configure~~</code>~~ script usually has been created with	+	For a ''GNU build system'' the '''configure''' script usually has been created with
-	* GNU ~~<code>~~autoconf~~</code>~~ and using	+	* GNU '''autoconf''' and using
-	* GNU ~~<code>~~automake~~</code>~~ and	+	* GNU '''automake''' and
-	* GNU ~~<code>~~libtool~~</code>~~.	+	* GNU '''libtool'''.

-	Further the source code author should 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. This is a feature which is used later in this description in order to prepare for packaging. In case the author did not confine to these rules you may '''try''' to fix this by using pack_sync script as described below.	+	Further the source code author should have used '''autoconf''', '''automake''' correctly and in compliance with the GNU coding standards by keeping directory output variables in the ''Makefile''s unexpanded. This allows to use <code>make install</code> and overriding install locations. This is a feature which is used later in this description in order to prepare for packaging. In case the author did not confine to these rules you may '''try''' to fix this by using '''pack_sync''' script as described below.

	'''1)''' Download the source to a preferred place:		'''1)''' Download the source to a preferred place:
Line 33:		Line 33:
	'''4)''' check which options are available for ./configure by executing		'''4)''' check which options are available for ./configure by executing
	./configure --help		./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.	+	'''5)''' configure the application with the right <tt>prefix</tt> for the final destination (e.g. <tt>/usr/local</tt>), '''instead of''' 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=... ...		./configure --prefix=/usr/local CC=... ...
	Further options to be considered may be --sysconfdir, --infodir, and --mandir		Further options to be considered may be --sysconfdir, --infodir, and --mandir
Line 40:		Line 40:
	'''7)''' Become root		'''7)''' Become root
	su		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 ...	+	'''8)''' Clean and prepare the temporary installation directory structure to which the package will be temporarily installed. 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 with the the wrong directory!		rm -rf PACKAGE # '''DANGER''' Don't do this with the the wrong directory!
	# Create temporary version of the ''prefix'' directory		# Create temporary version of the ''prefix'' directory
	mkdir -p PACKAGE/usr/local		mkdir -p PACKAGE/usr/local
-	'''9)''' Install the compiled application ~~then 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~~.	+	'''9)''' Install the compiled application into your temporary packaging directory. For that you need to temporarily overriding the <tt>prefix</tt> setting. This installation must not trigger a recompilation, and it won't if the software author has created the configure system correctly. The installation 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> when <code>configure</code> was run.
	make install prefix=PACKAGE/usr/local		make install prefix=PACKAGE/usr/local
	Further options to be specified may be infodir and mandir.		Further options to be specified may be infodir and mandir.
-

	== Building Non-''GNU build system'' Software ==		== Building Non-''GNU build system'' Software ==

77.128.157.40 at 09:57, 10 March 2007

77.128.157.40 — Sat, 10 Mar 2007 09:57:42 GMT

← Older revision		Revision as of 09:57, 10 March 2007
Line 8:		Line 8:
	The remainder of this article further assumes you have all the common development tools installed.		The remainder of this article further assumes you have all the common development tools installed.

-	== ''GNU build system'' based Software ==	+	== Building ''GNU build system'' based Software ==

	Many, but not all free software is build as, or structured in a similar way, to what the FSF established as the ''GNU build system''. The most apparent hint, but not an absolute proof, is the existence of an <code>configure</code> script which is supposed to be run to configure the build system for the current platform.		Many, but not all free software is build as, or structured in a similar way, to what the FSF established as the ''GNU build system''. The most apparent hint, but not an absolute proof, is the existence of an <code>configure</code> script which is supposed to be run to configure the build system for the current platform.
Line 47:		Line 47:
	make install prefix=PACKAGE/usr/local		make install prefix=PACKAGE/usr/local
	Further options to be specified may be infodir and mandir.		Further options to be specified may be infodir and mandir.
-
-	~~'''10a)''' Either build a nice tarball package:~~
-	~~tar cvzf <appname>_<architecture>.tar.gz -C PACKAGE .~~
-	~~where architecture is ppc for LS1/HG/HS, mips for the LS2 and arm9 for the LS Pro~~
-
-	~~If you like to use a common directory for all these packages, you may specify something like~~
-	~~tar cvzf ../PACKAGES/<appname>_<architecture>.tar.gz -C PACKAGE .~~
-
-	~~'''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.~~


-	== Non-''GNU build system'' ==	+	== Building Non-''GNU build system'' Software ==
	In case the software author didn't create the configuring system as properly		In case the software author didn't create the configuring system as properly
	as assumed by the previous step you may fix this by pack_sync tool.		as assumed by the previous step you may fix this by pack_sync tool.
Line 101:		Line 85:
	<br\>- pack_sync doesn't provide an undo of it's replacements.		<br\>- pack_sync doesn't provide an undo of it's replacements.

-	~~Please find a discussion about sense or non-sense of pack_sync toolin~~ the ~~discussion area.~~	+	'''10)''' Continue with the [[#Package the built Software\|next chapter]]

-	~~'''11)''' Continue as root, package~~ the ~~data up~~.~~<br>~~	+	Please find a discussion about sense or non-sense of pack_sync tool in the discussion area.

-	'''~~10a~~)''' or '''~~10b~~)'''	+	== Package the built Software ==
-	~~Same~~ as ~~above~~.	+
-	<~~!--~~	+	=== Overview ===
-	----	+	After the software has finally been build (see the previous chapters), one can now wrap the stuff up in a package for distribution. A simple package would be a [[tar]] file, a more convenient package would be an [[ipkg]] package. The following sections describe both alternatives.
-	No, ~~you have a package which often has pathes compiled into~~ it.	+
		+	Scripting the build as described above, and the packaging might make sense, instead of typing the same commands again and again.
		+
		+	=== Package as a tar File ===
		+
		+	'''tar''' is the traditional Unix archiving program, which is still popular in the Unix and also Linux world. It was originally intended for tape archives, but for ages it is used for file archives. These days a '''tar''' file is often compressed in addition, to reduce its size.
		+
		+	For packing the built software perform the following steps:
		+
		+	'''p1)''' Become (or stay) root.
		+	'''p2)''' Pack and compress the data in one go
		+	tar cvzf <appname>_<architecture>.tar.gz -C PACKAGE .
		+	where architecture should be ppc for LS1/HG/HS, mips for the LS2 and arm9 for the LS Pro.
		+
		+	That's it.
		+
		+	=== Package as an ipkg ===
		+
		+	'''[[ipkg]]''' is the package management tool chosen for [[OpenLink]]. Building ipkg packages is much simpler than it might appear at first sight. This wiki contains rater extensive ipkg documentation, particular [[Construct ipkg packages (for developers)]].
		+
		+	The following is just a quick rundown of what to do, so one doesn't get distracted by the multiple ways of creating an ipkg package. The details can be found in the referenced documentation.
		+
		+	# Decide if additional install and remove scripts are needed. E.g. to automate otherwise tricky setup steps, to display a license during install, to ask the user for some configuration parameters, to merge existing configuration, etc.
		+	#Write the script(s), if any.<br>See [[Construct ipkg packages (for developers)#Scripts]] for details.
		+	# Create a package description (<tt>control</tt>) file. This is mandatory.<br>See [[Construct ipkg packages (for developers)#CONTROL/control file (mandatory)]] and [[Construct ipkg packages (for developers)#Sample CONTROL/control files]] for details.
		+	#Become (or stay) root.
		+	#Create a directory called <tt>CONTROL</tt> in your <tt>PACKAGE</tt> directory:<br><code>mkdir PACKAGE/CONTROL</code>
		+	#Store the scripts (if any), and the <tt>control</tt> file in the <tt>PACKAGE/CONTROL</tt> directory and give them proper file access rights:<br><code>cp <scripts ...> control PACKAGE/CONTROL; chmod a+rx PACKAGE/CONTROL/<scripts ...>; chmod a+r PACKAGE/CONTROL/control</code>
		+	# Run '''ipkg-build''':<br><code>ipkg-build -c PACKAGE</code> <br>See [[Construct ipkg packages (for developers)#Using ipkg-build from ipkg-utils]] for details, but ignore the statements about tedious setup. That "tedious" setup was already performed by building the software in the <tt>PACKAGE</tt> directory as described in one of the above chapters.
		+
		+	That's it.

-	~~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)~~
-	~~-->~~
	[[Category:Development]]		[[Category:Development]]

77.128.162.13 at 21:57, 8 March 2007

77.128.162.13 — Thu, 08 Mar 2007 21:57:52 GMT

← Older revision		Revision as of 21:57, 8 March 2007
Line 1:		Line 1:
	{{Template:Articles}}		{{Template:Articles}}
		+	__TOC__
	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]]).		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]]).
	In the first section it is assumed that the software source follows a common structure and comes with a common mechanism (''GNU build system'') to build it. In the section chapter a workaround is described for getting along with other cases.		In the first section it is assumed that the software source follows a common structure and comes with a common mechanism (''GNU build system'') to build it. In the section chapter a workaround is described for getting along with other cases.

77.128.162.13 at 21:53, 8 March 2007

77.128.162.13 — Thu, 08 Mar 2007 21:53:20 GMT

← Older revision		Revision as of 21:53, 8 March 2007
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]]).	+	{{Template:Articles}}
-	In section A) it is assumed that the software source follows a common structure and comes with a common mechanism (''GNU build system'') to build it.	+	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]]).
-	In section B) a workaround is described for getting along with other cases.	+	In the first section it is assumed that the software source follows a common structure and comes with a common mechanism (''GNU build system'') to build it. In the section chapter a workaround is described for getting along with other cases.
		+
		+	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.		The remainder of this article further assumes you have all the common development tools installed.

-	''~~'A)'~~'' ''GNU build system''	+	== ''GNU build system'' based Software ==
-	~~A SW package complying~~ to ~~this common standard must~~ be ~~starting with~~	+
-	* a <code>configure</code> script~~, made~~ with	+	Many, but not all free software is build as, or structured in a similar way, to what the FSF established as the ''GNU build system''. The most apparent hint, but not an absolute proof, is the existence of an <code>configure</code> script which is supposed to be run to configure the build system for the current platform.
		+
		+	For a ''GNU build system'' the <code>configure</code> script usually has been created with
	* GNU <code>autoconf</code> and using		* GNU <code>autoconf</code> and using
	* GNU <code>automake</code> and		* GNU <code>automake</code> and
	* GNU <code>libtool</code>.		* GNU <code>libtool</code>.

-	Further the source code author should 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. This is a feature which is used later in this description in order to prepare for packaging. In case the author did not	+	Further the source code author should 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. This is a feature which is used later in this description in order to prepare for packaging. In case the author did not confine to these rules you may '''try''' to fix this by using pack_sync script as described below.
-	confine to these rules you may '''try''' to fix this by using pack_sync script as described below.	+
-		+
-	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.	+

	'''1)''' Download the source to a preferred place:		'''1)''' Download the source to a preferred place:
Line 63:		Line 64:


-	~~'''B)''' Workaround for non~~-''GNU build system''	+	== Non-''GNU build system'' ==
	In case the software author didn't create the configuring system as properly		In case the software author didn't create the configuring system as properly
	as assumed by the previous step you may fix this by pack_sync tool.		as assumed by the previous step you may fix this by pack_sync tool.

Ls2newbee at 20:13, 6 March 2007

Ls2newbee — Tue, 06 Mar 2007 20:13:47 GMT

Show changes

Ls2newbee at 22:51, 27 February 2007

Ls2newbee — Tue, 27 Feb 2007 22:51:27 GMT

← Older revision		Revision as of 22:51, 27 February 2007
Line 51:		Line 51:
	Note that pack_sync may be called as often as you like but it doesn't have an undo.		Note that pack_sync may be called as often as you like but it doesn't have an undo.

-	Please find a discussion about sense or non-~~senseofpack_sync~~ toolin the discussion area.	+	Please find a discussion about sense or non-sense of pack_sync toolin the discussion area.

	'''10a)''' In case the software author didn't create the configuring system as properly		'''10a)''' In case the software author didn't create the configuring system as properly

Ls2newbee at 22:50, 27 February 2007

Ls2newbee — Tue, 27 Feb 2007 22:50:35 GMT

← Older revision		Revision as of 22:50, 27 February 2007
Line 51:		Line 51:
	Note that pack_sync may be called as often as you like but it doesn't have an undo.		Note that pack_sync may be called as often as you like but it doesn't have an undo.

-	~~''This doesn't make sense. The mentioned tool does not change any hard-coded pathes compiled into binaries. These are, however, the ones who make trouble. Applications use hard coded pathes to~~ find other component of themselves. This is not the cleverest idea, but many do. E.g. gcc does this. That is the reason why an applications must be '''compiled''' for the place where it will finally be installed. You can't compile this stuff for another location and fix it afterwards [well, in theory you can, but that is a ~~tricky procedure, reshuffling the contents of object files)]. You either have a build system which supports this (e.g. a GNU build system),~~ or ~~you have to hack the build system until it complies. Running a diff on the binaries later will not fix the problem.''~~	+	Please find a discussion about sense or non-senseofpack_sync toolin the discussion area.
-		+
-	~~==> ls2newbee: Sorry if I wasn't clear enough. pack_sync does not patch any files.~~	+
-	~~The idea was to install the package first to the running system. These files wil reside there where they shouldbe at any other installation.~~	+
-	In a second step the whole installation is done again from scratch now targeting to a PACKAGE directory for creation of a tarball of compiled executables. This second make may compile wrong pathnames because the files actually do not reside where they should be on the target system (as on any system). So pack_sync is able to replace the files in the PACKAGE directory (having wrong hard coded path names) by the files of the first installation (having correct hard coded path names). For this purpose it compares files	+
-	~~of the 2nd 'tarball' installation with the corresponding files of the 1st 'real' installation. The result is~~ - ~~in theory - a tarball with correct path names because~~ the ~~files are actually taken from the living system (i~~.~~e. from the first installaion).~~	+
-		+
-	~~In other words:~~	+
-	~~If pack_sync replaced all files by those of the running system (correct paths!),~~	+
-	~~you'd get a correct tarball. However there is no need to replace files if there is no difference.~~	+
-		+
-	~~If you have any questions, please feel free to send me a private message.~~	+
-	**Please delete these comments/replace with final statement after the discussion has lead to a final result (ls2newbee)	+

	'''10a)''' In case the software author didn't create the configuring system as properly		'''10a)''' In case the software author didn't create the configuring system as properly