Building a Debian package from a source tarball - Revision history

Jpye: /* Installing the resulting packages */

2026-02-07T22:58:11Z

Installing the resulting packages

← Older revision		Revision as of 22:58, 7 February 2026
Line 33:		Line 33:
	To install your freshly-build ASCEND .deb packages, you can just		To install your freshly-build ASCEND .deb packages, you can just

	<source lang="sh">cd ~/ascend		<source lang="shellscript">cd ~/ascend
	sudo dpkg -i *.deb</source>		sudo dpkg -i *.deb</source>

Jpye: /* Using dtar to build a binary .deb for ASCEND */

2026-02-07T22:58:02Z

Using dtar to build a binary .deb for ASCEND

← Older revision		Revision as of 22:58, 7 February 2026
Line 18:		Line 18:
	To create a binary package for ASCEND, place the ''dtar'' script on your path, and obtain a source code tarball for ASCEND. Then run <tt>dtar</tt>. For example,		To create a binary package for ASCEND, place the ''dtar'' script on your path, and obtain a source code tarball for ASCEND. Then run <tt>dtar</tt>. For example,

	<source lang="sh">cd ~		<source lang="shellscript">cd ~
	svn co svn://ascend.cheme.cmu.edu.au/ascend/code/trunk ascend		svn co svn://ascend.cheme.cmu.edu.au/ascend/code/trunk ascend
	cd ascend		cd ascend

Jpye: /* Problems and improvements */

2010-12-22T08:32:06Z

Problems and improvements

← Older revision		Revision as of 08:32, 22 December 2010
Line 49:		Line 49:

	It would also be good if some better way of packaging debian/* files could be worked out. Something like the .spec file format could be conceived, which some preprocessing capability added. That would allow conditional generation of distro-specific debian metafiles by dtar.		It would also be good if some better way of packaging debian/* files could be worked out. Something like the .spec file format could be conceived, which some preprocessing capability added. That would allow conditional generation of distro-specific debian metafiles by dtar.

			The changelog text file embedded within the debian/* archive contains the email address of the person who packaged the file. This email address is also used to refer to the GPG key that must be used to successfully sign the resulting file. If that signature is not available, the package building process currently fails. Instead, a warning should be returned that unsigned packages were produced.


	[[Category:Miscellany]]		[[Category:Miscellany]]
	[[Category:Development]]		[[Category:Development]]

Jpye: /* Problems and improvements */

2010-11-09T01:05:01Z

Problems and improvements

← Older revision		Revision as of 01:05, 9 November 2010
Line 42:		Line 42:
	This script works pretty nicely for local building of a binary package. It means that you can install your package in such a way that you don't have to worry about remembering how to remove it later, and you don't have to remember complicated commands to build new versions of your package: you just need to (manually) update the 'debian/changelog' when you want to make a new release.		This script works pretty nicely for local building of a binary package. It means that you can install your package in such a way that you don't have to worry about remembering how to remove it later, and you don't have to remember complicated commands to build new versions of your package: you just need to (manually) update the 'debian/changelog' when you want to make a new release.

	A problem still exists, which is that, when attempting to correct minor packaging problems when using packaging tools such as ~~<a href="~~https://launchpad.net/ubuntu/+ppas~~" class="external text" title="https://launchpad.net/ubuntu/+ppas" rel="nofollow">~~Ubuntu PPA~~</a>~~, if you attempt to upload multiple different version of the same source code tarball using 'dput', your package will be rejected. So we need a way to build a package by somehow using a 'delta' between an old tarball and a new one.		A problem still exists, which is that, when attempting to correct minor packaging problems when using packaging tools such as [https://launchpad.net/ubuntu/+ppas Ubuntu PPA], if you attempt to upload multiple different version of the same source code tarball using 'dput', your package will be rejected. So we need a way to build a package by somehow using a 'delta' between an old tarball and a new one.

	A partial solution to this problem has been implemented, which is the option to allow all the debian/* files to be packaged in a separate 'debian metafiles tarball' (debian.tar.gz, as indicated in the suggested usage above). This approach works well with the ~~<a href="~~https://build.opensuse.org/~~" class="external text" title="https://build.opensuse.org/" rel="nofollow">~~OpenSUSE Build Service~~</a>~~, but is cumbersome in general, because there is nothing to detect whether or not the tarball has changed and needs to be renumbered/renamed.		A partial solution to this problem has been implemented, which is the option to allow all the debian/* files to be packaged in a separate 'debian metafiles tarball' (debian.tar.gz, as indicated in the suggested usage above). This approach works well with the [https://build.opensuse.org/ OpenSUSE Build Service], but is cumbersome in general, because there is nothing to detect whether or not the tarball has changed and needs to be renumbered/renamed.

	A better solution would be to somehow cache the last uploaded version of the tarball, and when a new tarball is encountered, to compare it and create a patch file as required. This is clearly processor-intensive, but the aim of this tool is to make packaging from tarballs easy, not to create the optimally efficient packaging system. The consequential practise from this packaging convention would be to only bump ASCEND version numbers after important changes have been made, because 'clean' tarballs will only be uploaded at a version number change.		A better solution would be to somehow cache the last uploaded version of the tarball, and when a new tarball is encountered, to compare it and create a patch file as required. This is clearly processor-intensive, but the aim of this tool is to make packaging from tarballs easy, not to create the optimally efficient packaging system. The consequential practise from this packaging convention would be to only bump ASCEND version numbers after important changes have been made, because 'clean' tarballs will only be uploaded at a version number change.

Jpye at 05:08, 10 July 2010

2010-07-10T05:08:35Z

← Older revision		Revision as of 05:08, 10 July 2010
Line 2:		Line 2:

	On RPM systems, one can tell people to download a generic ''myprog.tar.bz2'' file and then run "<tt>rpmbuild -ta myprog.tar.bz2</tt>". However, there is no comparable option in the Debian world. The only requirement for the 'rpmbuild -ta' command is that the tarball contain a 'myprog.spec' file inside. RPM also has a spec file that includes support for a 'preprocessor' language, allowing a single .spec file to be crafted for a wide range of architectures; this again is a lack that makes distribution of Debian-capable tarballs impossible across a range of distros/releases.		On RPM systems, one can tell people to download a generic ''myprog.tar.bz2'' file and then run "<tt>rpmbuild -ta myprog.tar.bz2</tt>". However, there is no comparable option in the Debian world. The only requirement for the 'rpmbuild -ta' command is that the tarball contain a 'myprog.spec' file inside. RPM also has a spec file that includes support for a 'preprocessor' language, allowing a single .spec file to be crafted for a wide range of architectures; this again is a lack that makes distribution of Debian-capable tarballs impossible across a range of distros/releases.


	This page presents a simple script, called ''<tt>dtar</tt>'' which tries to perform an equivalent task in the Debian world.		This page presents a simple script, called ''<tt>dtar</tt>'' which tries to perform an equivalent task in the Debian world.
Line 12:		Line 11:

	This script needs you to first install the packages ''python-debian'' and ''python-apt'' from the Ubuntu repositories.		This script needs you to first install the packages ''python-debian'' and ''python-apt'' from the Ubuntu repositories.


	If you have any feedback about ''dtar'', [[User:Jpye\|let me know]].		If you have any feedback about ''dtar'', [[User:Jpye\|let me know]].
Line 19:		Line 17:

	To create a binary package for ASCEND, place the ''dtar'' script on your path, and obtain a source code tarball for ASCEND. Then run <tt>dtar</tt>. For example,		To create a binary package for ASCEND, place the ''dtar'' script on your path, and obtain a source code tarball for ASCEND. Then run <tt>dtar</tt>. For example,


	<source lang="sh">cd ~		<source lang="sh">cd ~
Line 53:		Line 50:
	It would also be good if some better way of packaging debian/* files could be worked out. Something like the .spec file format could be conceived, which some preprocessing capability added. That would allow conditional generation of distro-specific debian metafiles by dtar.		It would also be good if some better way of packaging debian/* files could be worked out. Something like the .spec file format could be conceived, which some preprocessing capability added. That would allow conditional generation of distro-specific debian metafiles by dtar.

			[[Category:Miscellany]]
			[[Category:Development]]

	[[Category:~~Miscellany~~]]

Jpye: /* Installing the resulting packages */

2010-07-10T05:08:08Z

Installing the resulting packages

← Older revision		Revision as of 05:08, 10 July 2010
Line 36:		Line 36:
	To install your freshly-build ASCEND .deb packages, you can just		To install your freshly-build ASCEND .deb packages, you can just

	<source lang="~~a4c~~">cd ~/ascend		<source lang="sh">cd ~/ascend
	sudo dpkg -i *.deb</source>		sudo dpkg -i *.deb</source>

	ASCEND will then be accessible from your Applications menu, you will have syntax highlighting of ASCEND when you use GEDIT ('Text Editor' in Accessories menu), and you can double-click ASCEND model files to run them or edit them.		ASCEND will then be accessible from your Applications menu, you will have syntax highlighting of ASCEND when you use GEDIT ('Text Editor' in Accessories menu), and you can double-click ASCEND model files to run them or edit them.


	== Problems and improvements ==		== Problems and improvements ==

Jpye: /* Using dtar to build a binary .deb for ASCEND */

2010-07-10T05:07:57Z

Using dtar to build a binary .deb for ASCEND

← Older revision		Revision as of 05:07, 10 July 2010
Line 21:		Line 21:


	<source lang="~~a4c~~">cd ~		<source lang="sh">cd ~
	svn co svn://ascend.cheme.cmu.edu.au/ascend/code/trunk ascend		svn co svn://ascend.cheme.cmu.edu.au/ascend/code/trunk ascend
	cd ascend		cd ascend

Grivan: /* Using dtar to build a binary .deb for ASCEND */

2010-07-09T20:40:58Z

Using dtar to build a binary .deb for ASCEND

← Older revision		Revision as of 20:40, 9 July 2010
Line 28:		Line 28:
	scons dist		scons dist
	# this will create dist/ascend-VERSION.tar.bz2 and dist/debian.tar.gz (whatever VERSION currently is)		# this will create dist/ascend-VERSION.tar.bz2 and dist/debian.tar.gz (whatever VERSION currently is)
	dtar dist/ascend-VERSION.tar.bz2 dist/debian.tar.~~bz2~~		dtar dist/ascend-VERSION.tar.bz2 dist/debian.tar.gz

	# this will create .deb, .dsc, .orig.tar.gz .diff.gz files in your ~/ascend directory</source>		# this will create .deb, .dsc, .orig.tar.gz .diff.gz files in your ~/ascend directory</source>

UploadBot: Restored page from Google Cache, uploaded by John Pye

2010-05-13T13:28:59Z

Restored page from Google Cache, uploaded by John Pye

New page

For a person who has learnt Linux packaging on RPM-based systems in the first instance, it is annoying to find that there is no easy way (that I can discern) for building a binary Debian package directly from a source code tarball. I'm talking here about a source code tarball that is somehow 'packaging aware', i.e. it includes certain metadata that the packaging utility can use.

On RPM systems, one can tell people to download a generic ''myprog.tar.bz2'' file and then run "<tt>rpmbuild -ta myprog.tar.bz2</tt>". However, there is no comparable option in the Debian world. The only requirement for the 'rpmbuild -ta' command is that the tarball contain a 'myprog.spec' file inside. RPM also has a spec file that includes support for a 'preprocessor' language, allowing a single .spec file to be crafted for a wide range of architectures; this again is a lack that makes distribution of Debian-capable tarballs impossible across a range of distros/releases.

This page presents a simple script, called ''<tt>dtar</tt>'' which tries to perform an equivalent task in the Debian world.

You can get dtar from our subversion repository, here:
{{src|tools/dtar/dtar}} (see also the {{src|tools/dtar/README.txt}}).

''dtar'' has been written as a general-purpose tool. Any source-code tarball that includes the '<tt>debian/*</tt>' files should be able to be built directly with it.

This script needs you to first install the packages ''python-debian'' and ''python-apt'' from the Ubuntu repositories.

If you have any feedback about ''dtar'', [[User:Jpye|let me know]].

== Using <tt>dtar</tt> to build a binary .deb for ASCEND ==

To create a binary package for ASCEND, place the ''dtar'' script on your path, and obtain a source code tarball for ASCEND. Then run <tt>dtar</tt>. For example,

<source lang="a4c">cd ~
svn co svn://ascend.cheme.cmu.edu.au/ascend/code/trunk ascend
cd ascend

export PATH=$PATH:~/ascend/tools/dtar
scons dist
# this will create dist/ascend-VERSION.tar.bz2 and dist/debian.tar.gz (whatever VERSION currently is)
dtar dist/ascend-VERSION.tar.bz2 dist/debian.tar.bz2

# this will create *.deb, *.dsc, *.orig.tar.gz *.diff.gz files in your ~/ascend directory</source>

== Installing the resulting packages ==

To install your freshly-build ASCEND .deb packages, you can just

<source lang="a4c">cd ~/ascend
sudo dpkg -i *.deb</source>

ASCEND will then be accessible from your Applications menu, you will have syntax highlighting of ASCEND when you use GEDIT ('Text Editor' in Accessories menu), and you can double-click ASCEND model files to run them or edit them.

== Problems and improvements ==

This script works pretty nicely for local building of a binary package. It means that you can install your package in such a way that you don't have to worry about remembering how to remove it later, and you don't have to remember complicated commands to build new versions of your package: you just need to (manually) update the 'debian/changelog' when you want to make a new release.

A problem still exists, which is that, when attempting to correct minor packaging problems when using packaging tools such as <a href="https://launchpad.net/ubuntu/+ppas" class="external text" title="https://launchpad.net/ubuntu/+ppas" rel="nofollow">Ubuntu PPA</a>, if you attempt to upload multiple different version of the same source code tarball using 'dput', your package will be rejected. So we need a way to build a package by somehow using a 'delta' between an old tarball and a new one.

A partial solution to this problem has been implemented, which is the option to allow all the debian/* files to be packaged in a separate 'debian metafiles tarball' (debian.tar.gz, as indicated in the suggested usage above). This approach works well with the <a href="https://build.opensuse.org/" class="external text" title="https://build.opensuse.org/" rel="nofollow">OpenSUSE Build Service</a>, but is cumbersome in general, because there is nothing to detect whether or not the tarball has changed and needs to be renumbered/renamed.

A better solution would be to somehow cache the last uploaded version of the tarball, and when a new tarball is encountered, to compare it and create a patch file as required. This is clearly processor-intensive, but the aim of this tool is to make packaging from tarballs easy, not to create the optimally efficient packaging system. The consequential practise from this packaging convention would be to only bump ASCEND version numbers *after* important changes have been made, because 'clean' tarballs will only be uploaded at a version number change.

It would also be good if some better way of packaging debian/* files could be worked out. Something like the .spec file format could be conceived, which some preprocessing capability added. That would allow conditional generation of distro-specific debian metafiles by dtar.

[[Category:Miscellany]]