Publish your open source software to Ubuntu PPA

For an individual, here is a simple guide to show you howto publish and host your own deb to Ubuntu PPA.

Checklist

1. An Ubuntu Machine

2. SSH Keys Ready

   Reference: [ssh-short-guide] (omitted)

3. Preparing your GPG Keys

   Reference: gpg-short-guide

4. Setting up a Launchpad Account (aka: Ubuntu One Account)
5. Creating your own PPA

6. Publishing a first test package

   1. Backstaging Information

      Reference: [creating deb from scratch]

      Reference: [creating deb from source tree]

   2. Preparing the source code
   3. Preparing the Debian package control files
   4. Building the source package
   5. Uploading the package

7. Using a PPA

   1. Installing the package
   2. Deleting a package

Write in front

In Linux distributions, package management can almost be divided into two major genres: rpm and deb.

Pacman and archlinux are just niche and will not be mentioned.

Zypper is just the upper layer of rpm, and has no essential difference with yum and dnf.

This article and recent similar articles focus on deb distribution. In [Making a deb package from scratch], we have introduced the construction of a binary package, so that the built deb package can be directly downloaded by the user and dpkg -i package.deb , which can be said to greatly improve the convenience of users. But this kind of deb package is not so easy to be publicly released into the package management system-it is not absolutely impossible, but you need to prepare too many auxiliary files for it.

In this article, we will talk about the introduction of source package. The premise of this method is that you are a source code builder and are familiar with the source code construction process. Then you can easily build a satisfactory distribution package with the package management system Debian New Maintainer Manual In addition to the deb installation package, this distribution package (Bundle) usually includes source code tarballs and auxiliary files with version tracking records. Using the tool dput provided by Debian, you can push the distribution package (Bundle) to a public server, and users can install it using apt install package, which is also the best distribution plan for Debian-based distributions.

The distribution package (Bundle) can be published to a public server that is officially certified and maintained by Debian/Unubtu, but this requires several prerequisites. You need to apply and obtain permission from the maintenance team.

If you want to provide a sufficiently formal and official ppa distribution, use the registration entry on the ppa official website:

• Register a project
• Register a team

But don't pollute any generational development.

In PPA Way

For independent developers, being accepted by the core source (main, restored, universe) is not an easy task. However, the open source world will not close, so ppa may be the best choice for independent developers.

PPA is the abbreviation of Personal Package Archive. As the name suggests, ppa represents an environment, platform, or infrastructure for individual developers to publish software packages.

PPA is carried by launchpad.net. Launchpad.net is a website maintained by Canonical. It allows software developers to freely distribute software here. Packages released through launchpad can enjoy almost the same treatment as core packages in the Ubuntu apt system through ppa. You can install a package from a ppa provided by:

$ sudo add-apt-repository ppa:hedzr/test-ppa
$ sudo apt update
$ sudo apt install testpackage

Canonical is the owner and operator of Ubuntu.com.

It is worth mentioning that ppa is a good example of back feeding. Now (at least since Debian 7) we can also directly use ppa to install software in the Debian native operating system, which is no longer unique to the Ubuntu system.

A typical example of using ppa for software package distribution is about the installation of Oracle Java SDK. Someone who is in trouble has established a ppa distribution point for it, which avoids going to the Oracle official website to register an account, manually confirm the license, download manually, and execute the installation package manually. The uncivilized way of the Java SDK package. However, strictly speaking, this is suspected of infringement, so I have long since stopped using Java development to engage in Golang development. If it fails, I will go to C++. Can I commit such stupid things as Java?

Preparation before release

premise

In order to publish to PPA, you need an Ubuntu system. Fortunately, in Windows, you can use the WSL environment, which is Ubuntu. In macOS, using VirtualBox and optionally using vagrant, you can easily get the Ubuntu Server environment, which is very lightweight and basically has no additional burden.

Specifically how to prepare your Ubuntu environment and how to connect to it is like transferring code to the environment (rsync YYDS). This article will not describe it. This is the basic knowledge. You are planning to contribute your personal strength to the Ubuntu community. If you don’t understand what I’m talking about, it’s really impossible to justify.

An auxiliary reference is in Ubuntu Server installation summary , here I introduce some tips to make your VM more useful.

In this Ubuntu system, install the necessary software packages:

sudo apt install gnupg dput dh-make devscripts lintian gpg fakeroot
sudo apt install git make build-essentials

Since our case is based on C++ code, build-essential is also installed.

SSH Key Ready

In Ubuntu, you already have an SSH environment, and you already have an SSH Key.

You may also have prepared a password-free sudo, which is not necessary, but it may be the best to do, otherwise entering the password may be very troublesome.

GPG Key Ready

In order to publish to PPA, you need to have GPG Key, and you need to publish it to keyserver.ubuntu.com.

GPG can be found in 161c144d6bcb9c GPG Short Guide . If you feel that you need to learn about GPG more systematically, you need to search for it. This is not a difficult problem-its threshold lies in: GPG is a concept closely related to the encryption system, so you need a lot of background knowledge to go deep. Understand and use it well-but this does not prevent ordinary people from being able to easily use GPG to do daily work such as signing, signing, encrypting and decrypting documents or emails.

GPG demarcates an identity, which is associated with one (or more) Email addresses to verify the identity. You need to use a stable mailbox to create a GPG Key (including public and private keys). We recommend that you create a 4096 bits key.

An important detail is that ppa can only use your master key to complete the package, or to be precise, you can only use the master key to sign the package to be distributed, after uploading, ppa can correctly verify the validity of the package. Because ppa does not accept subkey when registering your GPG public key.

Maybe this is not true, maybe just because of the network environment, because for well-known reasons, there are many problems with walking between pages on the launchpad. I am not sure whether the network packet loss, congestion, etc. will affect the registration of GPG Key has an impact.

But I don't want to consume more energy for this.

As a workaround, you have created a GPG key on your host, and you can continue to create sub-keys. Then you will export your own master key (private key + public key). Be careful not to export the sub-key at this time, and then import the exported key to the Ubuntu system to complete the signature well.

Environment variable

For deb building, we add environment variables in .bashrc:

DEBEMAIL="[e-mail]"
DEBFULLNAME="your fullname"
export DEBEMAIL DEBFULLNAME
#DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -us -uc"
#DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
DEBSIGN_KEYID="Your_GPG_keyID"
export DEBSIGN_KEYID

Please correct the variable value by yourself.

Launchpad account

PPA is a software package distribution path provided by launchpad.net. So you must first visit launchpad.net/+login apply for a launchpad account.

What you need to know is that launchpad.net is operated by Canonical, and Ubuntu.com is also operated by their family, so the launchpad account is actually an Ubuntu One account. This group of sites is a family.

Therefore, the application link will jump to the Ubuntu One registration page.

It should be noted here that the email address used to apply for an account must be the same address used by GPG Key.

Not much to say, after applying for an account, first confirm that the email address is valid, and then add your SSH and GPG Key to your user center page. Suppose you have registered an account with the username hedzr, then your page is at https://launchpad.net/~hedzr , in this page, add SSH Key, GPG Key to the corresponding entries, and then your The page looks more like the picture below:

Among them, the link to OpenPGP keys https://launchpad.net/~hedzr/+editpgpkeys

Add SSH Keys link to https://launchpad.net/~hedzr/+editsshkeys

Create PPA

Now you can use the link Create a new PPA create your first ppa.

This step is very simple, there will be no domestic features, and it can be done directly and clearly.

There is no obvious limit to the number of ppas you can create. Each ppa usually has a capacity of 2GB. So our requires that you first create a PPA named test-ppa to do the following work.

The created ppa has ppa:<username>/<ppa-name>, and users will use this syntax to add your ppa:

sudo apt-add-repository ppa:hedzr/test-ppa

Please replace the necessary fields yourself.

Publish your first package

We already know that there are two ways to build deb:

1. Build the deb from the binary package:

   • Reference: Make deb files from scratch-Create .deb From Scratch

2. Build the deb from the source package:

   • Publishing to ppa requires you to submit source code, and your source code must be compilable. The extension of this topic will be huge.

This article uses C/C++ source code as an example to explain the latter (Source Package method).

Prepare source code

In Ubuntu, we started publishing work $HOME

The first is to create a working directory testpackage and add a source package. The so-called source package generally contains the source code and the scripts required for the build, usually Makefile, or CMakeLists.txt, etc.

Work list

The first is to create a working directory:

mkdir -pv ~/deb/testpackage.work/testpackage
cd ~/deb/testpackage.work/testpackage

1. We will do multiple jobs, so in general it is deb/;
2. The build of .deb is output to the upper-level directory of the source package, so we use the two-level directory structure of testpackage.work/testpackage to place the source files
3. In the future, .deb files will be exported to testpackage.work/.

C source code main.c

And create a main.c in place:

cat > main.c <<EOF
#include <stdio.h>

int main()
{
  printf("Hello world!\n");
}
EOF

C project build Makefile

Then there is Makefile, this Makefile must have two Targets, all and install.

In fact, only install is necessary. In addition make must be able to construct the corresponding binary result and be used correctly by install.

Knowledge of Makefile is also difficult to explain concisely. So you first need a Makefile like this:

BINDIR := /usr/bin

all:
    gcc main.c -o my_hello_world

install:
    mkdir -p ${DESTDIR}${BINDIR}
    cp my_hello_world ${DESTDIR}${BINDIR}/

We create it directly using the command line:

echo -e 'BINDIR := /usr/bin

all:
\tgcc main.c -o my_hello_world

install:
\tmkdir -p ${DESTDIR}${BINDIR}
\tcp my_hello_world ${DESTDIR}${BINDIR}/
' > Makefile

Note that in order to ensure the correct format of the Makefile (the command sequence of each target must be indented with TAB tabs), we use echo -e and explicitly use \t escape characters to express indentation.

You can try to build in the working directory:

make all

We already know that the ppa server will use the build server to build the source package we uploaded. At this time, ${DESTDIR} will be set by the build server to a local value. But for our local build or when the user builds via apt install, it usually does not specify a value.

${BINDIR} is preset to the value /usr/bin , which is also the default destination for the executable file of the installation package.

Create the source information and control files of the software package based on the source code package

The C source code is very simple, now we have to create a debian folder and a series of control files:

dh_make -p testpackage_0.0.0.1 --single --native --copyright apache --email $DEBEMAIL

You can choose other copyright agreements, such as mit and so on.

Version number: It should be 4 sections. The first three sections are usually used. The last section is only used when an emergency patch is released. Also refer to the instructions in the semver and debian new maintainer's manual.

For the deb source package construction method, it uses a debian folder to place the control files needed for deb packaging.

This is different from the DEBIAN folder of the binary package.

dh_make will ask you some questions, and after the answers, there will be a series of files in the debian folder. The file named *.ex is optional, such as postinst.ex. If you want to write a postinst script, you can rename it to postinst. This file already contains the necessary skeletons. You can focus on your Logically. But if you don't need to write a postinst script, then postinst.ex can be safely deleted:

rm debian/*.{ex,EX}

After dh_make runs, the generated files are all in debian/:

Review control documents

debian/README*

These files provide document descriptions, and you can modify them to express the purpose of your package.

debian/changelog

The most important file, whenever you upgrade, you need to add the description of the new version in it. Without the correct section of the new version description information, the upload and release cannot be completed successfully.

We need to revise this document:

perl -i -pe "s/unstable/$(lsb_release -cs)/" debian/changelog

Because what we need is an installation package for a specific Ubuntu version (20.04 in the case), the multiarch or any mode will not be involved for the time being.

Now its content looks like this, where unstable has been replaced with focal :

testpackage (0.0.0.1) focal; urgency=medium

  * Initial Release.

 -- hedzr <[e-mail]>  Tue, 07 Dec 2021 09:36:35 +0000

The following description of the upgrade part will further elaborate on this document.

debian/control

The same important file, this file will be refactored to DEBIAN/control during debuild.

Control contains the description information of the software package, and its key information basically comes from your answer when dh_make.

We still need to revise the newly generated control a little bit, usually involving Section, Homepage, Vcs-Browser, Vcs-git, Description and other fields. You need to set these values according to your specific situation.

The revised control looks like this:

Source: testpackage
Section: utils
Priority: optional
Maintainer: hedzr (hz, hedzr) <[e-mail]>
Build-Depends: debhelper-compat (= 12)
Standards-Version: 4.4.1
Homepage: https://testpackage.foobar.org
Vcs-Browser: https://github.com/foobar/testpackage
Vcs-Git: https://github.com/foobar/testpackage.git

Package: testpackage
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: A short description
  A long description,
  very long indeed!

The Description field can be multiple lines and must be the last field. The beginning of a multi-line text must be indented by at least one space.

debian/rules

In the source package building, rules may be the most important file, because it provides you with the opportunity to customize and modify the standard compilation and build behavior.

Rules are not described in detail in this article, because this is a huge topic that challenges individual abilities. We use the default generated version without any changes:

#!/usr/bin/make -f
# See debhelper(7) (uncomment to enable)
# output every command that modifies files on the build system.
#export DH_VERBOSE = 1


# see FEATURE AREAS in dpkg-buildflags(1)
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all

# see ENVIRONMENT in dpkg-buildflags(1)
# package maintainers to append CFLAGS
#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
# package maintainers to append LDFLAGS
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed


%:
    dh $@


# dh_make generated override targets
# This is example for Cmake (See https://bugs.debian.org/641051 )
#override_dh_auto_configure:
#    dh_auto_configure -- #    -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)

In the next feature article, we will make adjustments to this document in a modest manner, and some relevant information will be introduced at that time. If you have a strong interest in this, then don't have to wait for our entry-level series of articles to be released, just go to Debian New Maintainer Manual to try and study.

More...

You can browse other files one by one and revise them as needed. But as the first software package for experimentation, that's it.

You can add scripts such as postinst, postrm, etc. There is no additional difference in this respect, so you can refer to to make deb files from scratch-Create .deb From Scratch , or refer to MaintainerScripts .

Note that dh_make has generated complete templates of these files for us, but they end with the .ex suffix, so when you want your own version, simply rename these skeleton files.

Sometimes you need to review whether the executable permissions of these script files are present and make sure they are at least 0755.

Let us move on to the next step.

Build a distributable package

Build debs and sign them with our dedicated subkey.

debuild -S -k$DEBSIGN_KEYID | tee /tmp/debuild.log 2>&1

-S means to compile and build from source code;

-us -uc specifies the options for signing;

The result is a set of file deb packages

testpackage_0.0.0.1.dsc
testpackage_0.0.0.1.tar.xz
testpackage_0.0.0.1_source.build
testpackage_0.0.0.1_source.buildinfo
testpackage_0.0.0.1_source.changes

Upload to our ppa

testpackage_0.0.0.1_source.changes is the information file needed for uploading. The testpackage_0.0.0.1.* we just generated can now be uploaded to our ppa:

Z="$(perl -ne 'print $1 if /dpkg-genchanges --build=source >(.*)/' /tmp/debuild.log)"
dput ppa:hedzr/testppa $Z

It is equivalent to:

dput ppa:hedzr/testppa testpackage_0.0.0.1_source.changes

Possible problems

gpg.errors.BadSignatures

If your GPG Key has several subkeys, this signature will not be correct enough, and the package file verification will fail before dput upload.

$ dput ppa:hedzr/test-ppa ../testpackage_0.0.0.1_source.changes
Checking signature on .changes
Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in <module>
    load_entry_point('dput===1.0.3ubuntu1', 'console_scripts', 'execute-dput')()
  File "/usr/share/dput/dput/dput.py", line 1030, in main
    files_to_upload = verify_files(
  File "/usr/share/dput/dput/dput.py", line 374, in verify_files
    verify_signature(
  File "/usr/share/dput/dput/dput.py", line 274, in verify_signature
    assert_good_signature_or_exit(changes_file_path)
  File "/usr/share/dput/dput/dput.py", line 258, in assert_good_signature_or_exit
    crypto.check_file_signature(infile)
  File "/usr/share/dput/dput/crypto.py", line 93, in check_file_signature
    (_, verify_result) = context.verify(infile)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 541, in verify
    raise errors.BadSignatures(results[1], results=results)
gpg.errors.BadSignatures: DA3963683E1153984E7FBE218D9B6C4242615E10: General error

The upload has not been completed at this time.

Ignore the signature to see more

If you want, you can add --unchecked to try again

dput --unchecked ppa:hedzr/testppa testpackage_0.0.0.1_source.changes

https://askubuntu.com/questions/818010/attempting-to-upload-to-my-ppa-the-signature-could-not-be-verified

The remaining upload process will be displayed:

$ dput -f -u  ppa:hedzr/test-ppa ../testpackage_0.0.0.1_source.changes
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading testpackage_0.0.0.1.dsc: done.
  Uploading testpackage_0.0.0.1.tar.xz: done.
  Uploading testpackage_0.0.0.1_source.buildinfo: done.
  Uploading testpackage_0.0.0.1_source.changes: done.
Successfully uploaded packages.

However, this is not true. Because dput works in dry-run mode at this time.

Solve the problem

The solution is to edit your GPG Key, delete all subkeys and only keep the main key:

$ gpg --edit-key 17AFB9B1
key 2
delkey
key 1
delkey
save

Assuming you have two subkeys, the above command sequence locates each subkey in turn, deletes it, and finally saves and exits.

This is to comply with the limitations of launchpad, they can only register your master key and can only verify with the master key.

Now delete the wrong package and repack it:

$ rm ../testpackage_*
$ debuild -S -k$DEBSIGN_KEYID | tee /tmp/debuild.log 2>&1
$ dput ppa:hedzr/test-ppa ../testpackage_0.0.0.1_source.changes
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading testpackage_0.0.0.1.dsc: done.
  Uploading testpackage_0.0.0.1.tar.xz: done.
  Uploading testpackage_0.0.0.1_source.buildinfo: done.
  Uploading testpackage_0.0.0.1_source.changes: done.
Successfully uploaded packages.

After a few minutes, you will receive a notification email from Launchpad, indicating that they have accepted the software package we just uploaded.

It can now be installed from your private ppa:

sudo add-apt-repository ppa:hedzr/test-ppa
sudo apt update
sudo apt install testpackage

It can be noticed that we are building a tarball in xz format, not a deb file. But this difference is not very important, because the nature is the same. In addition, remember the format of deb that we introduced earlier, it is just a bundled combination of the control file xz package and the content file xz package (in ar format), so there is actually no difference.

Solve the problem from the source

The server used for packaging is often not your main working machine, so the gpg keyrings on this server are actually constructed by importing your gpg private key file.

When you export the private key on the main work machine, you can use the ! suffix to request that only the specified key is exported, and the subkeys are not exported:

gpg --armor --output user.gpg.private.key.asc --export-secret-keys MASTER-KEYID!

In doing so, only the master key will be left after the server is imported.

Similarly, in some other places, there are the same situations that require precise designation instead of the best match. You can use the ! suffix Dafa.

Error: signing key fingerprint does not exist

When I tested testpackage for the first time, I could understand your urgency, because I was like that back then. But the fact is that you have to be patient. After successfully uploading locally, you will not immediately see the status update of the launchpad ppa, and you will not receive the email immediately. If your package is large and time-consuming to build, then this situation will more serious. Rest assured, it will.

In addition, if you receive an email and want to try to install and test soon, then you may receive an error that the key does not exist:

$ sudo add-apt-repository ppa:hedzr/test-ppa
 for testing
 More info: https://launchpad.net/~hedzr/+archive/ubuntu/test-ppa
Press [ENTER] to continue or Ctrl-c to cancel adding it.

Error: signing key fingerprint does not exist
Failed to add key.

BE PATIENT. Launchpad actually needs to create a new GPG Key for your ppa. This GPG Key takes a little time to upload to keyserver.ubuntu.com and it takes a little time to complete synchronization and distribution in the pool, so wait a minute, Retry, you won't be troubled here for too long.

Other Information

Launchpad PPA for You

If you are a little curious about this new key, you can take a look at it:

$ apt-key list <Your_launchpad_username>

For example:

$ apt-key list hedzr
pub   rsa4096 2021-12-07 [SC]
      4AE7 90DF 4985 3D9E 55DE  41F9 A6E8 3CC2 BF06 44DD
uid           [ unknown] Launchpad PPA for Hedzr Yeh

Confirm testpackage information

# 查看 包信息 
apt info testpackage

# 显示包中文件
dpkg -L testpackage

Install testpackage as a user

In the user interface, he needs to do these things to install your testpackage:

$ sudo add-apt-repository ppa:hedzr/test-ppa
$ sudo apt update    # optional
$ sudo apt install testpackage

Upgrade to new version

When you are ready to release the next version, you only need to revise the debian/changelog for the debian control file. A sample looks like this:

testpackage (0.0.0.2) focal; urgency=medium

  * Updated: fixed build error in source codes

 -- hedzr <[e-mail]>  Tue, 08 Dec 2021 09:28:35 +0000

testpackage (0.0.0.1) focal; urgency=medium

  * Initial Release.

 -- hedzr <[e-mail]>  Tue, 07 Dec 2021 09:36:35 +0000

You can use dch -i or dch -v version-revision to modify the changelog file.

The next step is to rebuild:

debuild -S -k$DEBSIGN_KEYID | tee /tmp/debuild.log 2>&1

Now there will be a new version generated:

-rw-r--r-- 1 hz hz 1569 Dec  8 01:29 ../testpackage_0.0.0.2.dsc
-rw-r--r-- 1 hz hz 7472 Dec  8 01:29 ../testpackage_0.0.0.2.tar.xz
-rw-r--r-- 1 hz hz 2354 Dec  8 01:29 ../testpackage_0.0.0.2_source.build
-rw-r--r-- 1 hz hz 6199 Dec  8 01:29 ../testpackage_0.0.0.2_source.buildinfo
-rw-r--r-- 1 hz hz 2033 Dec  8 01:29 ../testpackage_0.0.0.2_source.changes

So you will upload it to ppa:

$ dput ppa:hedzr/test-ppa ../testpackage_0.0.0.2_source.changes
Checking signature on .changes
gpg: ../testpackage_0.0.0.2_source.changes: Valid signature from 2E6F77F217AFB9B1
Checking signature on .dsc
gpg: ../testpackage_0.0.0.2.dsc: Valid signature from 2E6F77F217AFB9B1
Uploading to ppa (via ftp to ppa.launchpad.net):
  Uploading testpackage_0.0.0.2.dsc: done.
  Uploading testpackage_0.0.0.2.tar.xz: done.
  Uploading testpackage_0.0.0.2_source.buildinfo: done.
  Uploading testpackage_0.0.0.2_source.changes: done.
Successfully uploaded packages.

Wait patiently, the new version will be released.

Check the release status on the PPA

For hedzr/test-ppa, look here: https://launchpad.net/~hedzr/+archive/ubuntu/test-ppa/+packages

The name of each package can be expanded. The Builds of the unsuccessful package have a link to the failed buildlog, and you can check why it failed.

A ppa is only 2GB in size, so the friendly use of public open source space may be more than a matter of politeness.

Bonus

When your package is stable enough, useful enough, and has entered the official ppa, or even when you enter the official source, the package of the same name installed in your personal ppa is a bit out of date.

ppa-purge allows users to easily clean up the packages installed from your personal ppa, and install and replace them with the official source or the same-named package from the official ppa source. Of course, if there is no official version of the same name in the official source yet, this package will remain unchanged.

sudo ppa-purge ppa:<lp-name>/<ppa-name>

Finish

This article extracts use cases from the following:

• Building a Debian (.deb) source package, and publishing it on an Ubuntu PPA – Saverio Miroddi

In fact, one of the early learning sources for this article is to a large extent this article.

Of course, my bigger teacher is Debian New Maintainer Manual . You should read it through patiently first, because this manual describes all the key concepts, and you must have at least an impression to understand each of the source package construction. Class details, such as how Depends should be set, etc.

However, to read it through, there is no need to rush to read it, but to run it with the help of this article, run an example by yourself, and then go back and read it more appropriately.

Then Debian Policy Manual is a very important reference manual. For Chinese, you need to face it without a Chinese translation, but its grammar is very simple. It is estimated to be difficult for children aged 5 or 6 to read. A certain vocabulary of the computer direction is required. What we mentioned, including all the debian/* files mentioned in the new maintainer's manual are detailed in the Policy manual, and you must refer to this manual if you want to write your own further control files.

I found that if I was determined to do one thing, of course I could do it. For a long time, I have avoided further research or learning on Packaging, and instead used a more convenient way to distribute (for example, you can download it on GitHub Releases), but simplicity may mean that it is not easy for users. This is why I have to face the professional packaging approach in the end. But since you have done some research, it is easy to find that some resources are there, but no one will deliberately remind you where something is. How to do it? Generally speaking, if you find a professional newsgroup like usnet, you have a higher probability of getting useful instructions when asking questions. But consumer-oriented such as Quora is not necessarily a good choice. What I must remind is that Discord or dev.to is not very helpful in the face of these detailed packaging issues that I have introduced. Of course, after all, you have to use Google to find the channels I mentioned, including those useful blog posts. Similarly, mine, I think, for some people, such an article that really introduces the main points should be very useful.

refer to

• Debian New Maintainer's Manual
• Debian Policy Manual
• Debian FAQ
• Building a Debian (.deb) source package, and publishing it on an Ubuntu PPA – Saverio Miroddi
• Creating and hosting your own deb packages and apt repo
• gpg-short-guide
• Make deb files from scratch

:end: