The tutorial you have linked uses a low level approach for building a package. Such an approach is not usually recommended and may lead to all sorts of issues when not done carefully.
Creating a .deb for a script is very simple once you understand packaging basics.
In a nutshell:
# Configure your paths and filenames
SOURCEBINPATH=~
SOURCEBIN=myscript.sh
DEBFOLDER=~/somescripts
DEBVERSION=0.1
DEBFOLDERNAME=$DEBFOLDER-$DEBVERSION
# Create your scripts source dir
mkdir $DEBFOLDERNAME
# Copy your script to the source dir
cp $SOURCEBINPATH/$SOURCEBIN $DEBFOLDERNAME
cd $DEBFOLDERNAME
# Create the packaging skeleton (debian/*)
dh_make -s --indep --createorig
# Remove make calls
grep -v makefile debian/rules > debian/rules.new
mv debian/rules.new debian/rules
# debian/install must contain the list of scripts to install
# as well as the target directory
echo $SOURCEBIN usr/bin > debian/install
# Remove the example files
rm debian/*.ex
# Build the package.
# You will get a lot of warnings and ../somescripts_0.1-1_i386.deb
debuild
Adding more scripts requires them to be copied to the directory and added to the debian/install file -- then just re-run debuild. You should also check and update the debian/* files as required .
You should read the man pages for: dh_make, dh_install, and debuild
Packages in the official archives have debug packages build for them automatically. They are stored in a different archive though. They will have the names foo-dbgsym You can access them by putting the following in your /etc/apt/sources.list:
deb http://ddebs.ubuntu.com natty main restricted universe multiverse
deb http://ddebs.ubuntu.com natty-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com natty-security main restricted universe multiverse
deb http://ddebs.ubuntu.com natty-proposed main restricted universe multiverse
(Replace natty with the release you are running.)
Information on how these are generated can be found here:
If you'd like to provide debug packages for a package which you maintain outside of the official archives, that is possible as well. This Debian wiki article is the best place to start.
Briefly, you must first create the new package in debian/control by adding:
Package: foo-dbg
Architecture: any
Section: debug
Priority: extra
Depends:
foo (= ${binary:Version}),
${misc:Depends}
Description: debugging symbols for foo
foo is a library that lets you do stuff.
.
This package contains the debugging symbols for foo.
Then in debian/rules, use dh_strip to strip debugging symbols from binaries, but retain them for use in the debug packages.
override_dh_strip:
dh_strip --dbg-package=foo-dbg
Best Answer
Package signing on Ubuntu/Debian systems is rather messy. In theory, signing a deb package makes it possible for the person receiving your package to verify that the package was not modified after you signed it. In reality, signature verification is terribly difficult to setup and is disabled by default. Unless the user does a bunch of setup locally, they won't be verifying the signature when the package is installed.
In order to sign a package, you can use either: debsigs or dpkg-sig. The signatures are not compatible with one another, so you'll need to make sure the user is using the proper tool on the receiving side for verifying signatures.
dpkg-sig is easier to use for both you and the user, but debsigs is the tool with built-in support (which is disabled by default) on Ubuntu and Debian.
I wrote a blog post containing all the technical details of signing and verifying source packages (.dsc files), binary packages (.deb), and APT package repositories themselves here: http://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/