Describing Project Tree
PROJECT DIRECTORY TREE
pw-project-root/ ----------------- LEVEL0
│
├── pipewire_0.3.26.orig.tar.gz (AT THIS LEVEL,All out comes after building
├── pipewire_0.3.26-3.debian.tar.xz Will be saved)
│
└── pipewire-0.3.26 ---------------- LEVEL1
│
├── pipewire_source_files-3 (YOUR BUILDING HOME DIR, FROM HERE ALL BUILDING
├── pipewire_source_files-2 RELATED COMMANDS WILL BE RUN)
├── pipewire_source_files-1
│
└── debian ------------------- LEVEL2
│
├── upstream
│ └── y
├── trigger
├── test
│ └── x
├── *.symbols
├── source
│ └── z
├── shilibs.local, *.shilibs.local, *.shilibs
├── rules
├── ${subpakcageName}.{pre,post}{rm,inst}
├── patches
│ ├── *.series
│ └── *.patch
├── *.maintscript, *.links, *.install
├── copyright
├── control
└── changelog
Download a new release of PW (file name ending with tar.gz) and rename to pipewire_0.3.xx.orig.tar.gz and place under project dir properly (See above tree).
untar this file and rename the untared dir projectName-version[-Arch] i.e. pipewire-0.3.xx
copy debian dir from github local repo and place under projectName-version[-Arch] i.e. pipewire-0.3.xx dir.
If you want to redestribute do necessory changes under debian/.
pw-project-root/ ------------------> LEVEL0
│
├── *.{ddeb,deb} ---------------------> (1) NEW After dpkg-buildpackage command + ---|
├── *.{dsc,changes,buildinfo} --------> (2) NEW After debuild command. < ------------|
│
├── pipewire_0.3.26.orig.tar.gz
├── pipewire_0.3.26-3.debian.tar.xz
│
TO OBTAIN LEVEL0's (1) && (2) ALL COMMANDS (debuild,buildpakcage) HAVE TO RUN UNDER LEVEL1
(1) && (2) these files will generate if you localy build with dpkg-buildpackage -b -rfakeroot [-uc] [-us] [-nc] [-k"Your_GPG_MailId"]
'-k' and "YOur_GPG_MailId" - Everything will be signed against your gpg signature. your gpg key will be identified by your
gpg mail,that you created while generating gpg key.
[-uc,-us] - don't sign;
-nc - don't compile again you previously compiled.
TO OBTAIN (2) only DON'T DO PREV. INSTRUCTION. THIS INSTRUCTION FOR LAUNCHPAD PPA TO BE UPLOADED. dput should run under LEVEL0.
(2) - ( "*.changes" file have all file's shachecksums that need to be uploaded to launchpad with dput)
( to upload to launchpad, at this level you have to run to generate (2) related files (debuild -S -sa with orig.tar.xz or
without orig.tar.xz debuild -S -sd) this will generate all files need to be uploaded.
for this under ~/.devscripts file you have to write a variable "DEBSIGN_KEYID=${YOUR_16CHAR_GPG_KEY_ID}"
WHAT IS GPG_KEY_ID - a short key 8 or 16 char long hexadecimal value of 40 char long gpg private key
How to find that key? - gpg --list-signatures - run this, you will find it on last line before date.
THIS SIGNATURE SHOULD MATCH WITH YOUR LAUNCHAPD SIGNATURE.
rules - Its syntax same as makefile defining how the main ${project_name} compiled, you can find all debhelper(package) based dh_automake or dh_${strings} commands. after compiling, unit test has been done, making all shlibs, find missing files and all etc. are done.
copyright - Not that much of important
changelog - your project's changelog. from here actual project versioning done. And it will define how your package is important to a system and for which distro_code_name. It also define list of changes since last released.And the last line it contains your Full Name with '<'EmailId'>' and 'date' obtained from date -R. debuild, dpkg-buildpakcage both sign 'changelog file' against your written mail id in changelog file's top. This email id should your gpg mail id.
When repackaging or Upgrading to a new version of your software, you must change the version from here, date obtaining from date -R, and you may put some changelogs. If you are repakcaging and you are thinking to redestribute you should change the "name" and "email" also.
EXAMPLE -
pipewire (0.3.26-3) focal; urgency=medium * New upstream release * New pw-link tool added, I18n support, Add logind support. * Many Bluetooth improvements, support for hardware volumes * Support for 64 channel devices. -- Sourav Das Sat, 24 Apr 2021 20:46:29 +0100
If you are building for multiple version of ubuntu, you need to must follow the naming convension
As changelog file determines what should you build name, you need to change here.
So the syntax is,
${PackageName} (${PackageVersion}-${NoOfRelease}~ubuntu${ubuntuVersion}) ${ubuntuCodeName}; urgency=medium
example-
pipewire (0.3.26-3~ubuntu20.04) focal; urgency=medium
And need to upload for each version of ubuntu you want to build against. If you need not to build from source
for a different version you need to copy the binaries for that version of ubuntu under launchpad.
control - This is huge to understand. Its better to read from here.The important term is listed.
Depends: ${misc:Depends},${shilibs:Depends} will find at buildtime and substitue this variable. you have no controls on them.
*.install -
If there are files that need to be installed into your package but your standard make install won't do it, put the filenames and destinations into this install file. They are installed by dh_install(1).[56] You should first check that there is not a more specific tool to use. For example, documents should be in the docs file and not in this one.
This install file has one line per file installed, with the name of the file (relative to the top build directory) then a space then the installation directory (relative to the install directory). One example of where this is used is if a binary src/bar is left uninstalled; the install file might look like:
src/bar usr/bin This means when this package is installed, there will be an executable command /usr/bin/bar.
Alternatively, this install can have the name of the file only without the installation directory when the relative directory path does not change. This format is usually used for a large package that splits the output of its build into multiple binary packages using package-1.install, package-2.install, etc.
The dh_install command will fall back to looking in debian/tmp for files, if it doesn't find them in the current directory (or wherever you've told it to look using --sourcedir).
*.links - symlinks
{pre,post}{inst,rm} - files are simple bash scripts.
`set -e` should be maintaioned. positional parameters has been set.
$1 : configure,purge,remove,abort-upgrade,abort-remove,abort-deconfigure
$2 : may exist don't know.
EXAMPLE
#!/bin/sh
# pipewire-audio-client-libraries.postinst, runs ldconfig
set -e
case "$1" in
configure)
ldconfig
;;
#abort-upgrade|abort-remove|abort-deconfigure)
*)
;;
esac
For More information See here
trigger - trigger some action at a instance.
*.maintscript - {pre,post}{inst,rm} scripts are called maintscript. As a novice maintainer, you should avoid any manual editing of maintainer scripts because they are problematic. For more information refer to the Debian Policy Manual, 6 "Package maintainer scripts and installation procedure", and take a look at the example files provided by dh_make. *** This should be deleted.
DpkgConffileHandling - Sometimes you need to handle with the user modified conf files. If you don't handle this situation a package removeation,
installalationv or reinsall can make seriouse accident that can lead to remove those modified conf files. In this case you can tell dpkg that to
run a script at a instant of a action, what to do with those conf files. you can do the following things :
If a package wants to install new conf files,
- you have to check whether its the same conf file (content wise) like the prev one.
If its the same you are fare to replace that file.
If its the not same you have to backup the old one and replace the new conf files. - If there are no conffiles already then don't run the scriipt further, you have to check this at the very first of the script.
read this and this tutorial for further information.
User interaction - You can Interact with the user before unpacking the package for the confirmation of some services to be stoped or
something else that need to be must done before unpacking the package. This is usally done in preinst script.
And there are many uses case, these 2 are only example.
*.patch && *.series - see it here and here or here
└── debian ------------------- LEVEL2
│
├── pipewire-bin
│ ├── DEBIAN/
│ │ ├── conffiles _____
│ │ ├── control |
│ │ ├── md5sums |
│ │ ├── postinst |------- All files, Rests are directory
│ │ ├── postrm |
│ │ ├── preinst |
│ │ └── prerm -----
│ ├── etc
│ │ └── pipewire
│ │ └── media-session.d
│ ├── lib
│ │ └── udev
│ │ └── rules.d
│ └── usr
│ ├── bin
│ └── share
│
├── pipewire-locales
├── libspa-0.2-bluetooth
├── .
├── .
├── .
├── .
├── .
├── etc
├── tmp (DESTDIR)
Under debian/ directory, all ${subPackage} dir will be created. These ${subPackage} are define in debian/control file under Package attribute of each section.
Under each ${subPackage} dir a DEBIAN/ dir is created, containing mainly control,md5sums. The DEBIAN/ may contain other files also.
control - It contains the same subsection of related sub package under debian/control file.
md5sums - md5checksums of files
debian-binary - only contains project version number
{post,pre}{inst,rm} - releated sub package's {post,pre}{inst,rm} file under debian/ directory.
conffiles - don't know.
other dirs under a subpackage_name dir are files to be insalled on a real root system.
