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

    [ssh-short-guide]

  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

      [creating deb from scratch]

      [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

Writing in the front

In Linux distributions, package management can be divided into almost two main schools: RPM and DEB.

Not to mention pacman and ArchLinux are niche.

Zypper is just an upper layer of RPM, not fundamentally different from YUM or DNF.

This article and similar recent articles have focused on DEB publishing. Deb = dkg.deb = dkg.deb = dkg.deb = dkg.deb = dkg.deb = dkg.deb = dkg.deb This deb isn’t as easily distributed to a package management system-not necessarily, but you’ll need too many auxiliary files for it.

In this paper, we will introduce the introduction of Source Package. If you are a source builder and are familiar with the source code build process, you can easily build distributions that are satisfactory to the package management system with the help of the New Debian Maintainer manual. In addition to the DEB installation package, the Bundle usually includes the source tarball, along with auxiliary files with version tracking records. Using the Debian tool Dput, you can push the Bundle to a public server. Users can install the Bundle using apt Install package, which is the best way to distribute Debian distributions.

Bundles can be published to public servers that are officially certified and maintained by Debian/Unubtu, but this requires several conditions. You need to ask for permission from the maintenance team.

If you are interested in providing a formal and official PPA release, use the registration portal on the PPA website:

  • Register a project
  • Register a team

But what generation development drift better not to do pollution.

In PPA Way

Getting accepted by the core source (main, restrited, Universe) is not an easy task for an indie developer. However, the open source world is not going to shut down, so PPA may be the best choice for indie developers.

PPA stands for Personal Package Archive, and as the name suggests, PPA represents an environment, platform, or infrastructure for individual developers to distribute packages.

PPA is hosted by Launchpad.net. Launchpad.net is a website maintained by Canonical, which allows developers to distribute their software freely. Launchpad packages in Ubuntu APT enjoy almost the same treatment as core packages via PPA. You can install packages from a PPA as follows:

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

Canonical is the owner and operator of Ubuntu.com.

It is worth mentioning that PPA is a good example of backfeeding, and now (at least as of Debian 7) we can also install ppa directly in the Debian native operating system, not only in Ubuntu.

A typical example of using PPA for software package distribution is the installation of Oracle Java SDK. Some helpers have established PPA distribution points for it, avoiding the need to register an account on Oracle official website, manually confirm the license, and manually download. Manually executing the installation package completes the Java SDK package in an uncivilized way. But strictly speaking, this is suspected of infringement, so I have long abandoned Java development to do Golang development, really not I go to C++, why do Java such stupid things.

Pre-release preparation

The premise

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

The details of how to prepare your Ubuntu environment and how to connect to it, such as transferring code to the environment (Rsync YYDS), will not be described in this article, but it is the basics, you are planning to contribute to the Ubuntu community, it is not easy to understand what I am talking about.

An auxiliary reference is in the Ubuntu Server Installation feed, where I introduce some tips to make your VM work better.

On this Ubuntu system, install the required packages:

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

Since our example uses C++ code as an example, build-essential is also installed.

SSH Key Ready

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

You may also have password-free Sudo ready, which is not required, but is probably best done, otherwise entering a password can be annoying.

GPG Key Ready

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

A quick reference to GPG can be found in the GPG Short Guide. If you feel you need to learn more about GPG in a systematic way, you need to do some research. It’s not too difficult — the threshold is: GPG is a concept closely related to encryption, so you need a lot of background knowledge to understand and use it well — but that doesn’t mean it’s easy for ordinary people to use GPG for everyday tasks like signing, signing, encrypting and decrypting documents or emails.

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

One important detail is that the PPA can only send packages using your master key, or to be more precise, you can only sign the package you want to distribute with your master key, and the PPA can verify the package’s validity after uploading. Because ppa does not accept subkey when registering your GPG public key.

Maybe that’s not true, or maybe it’s just the network environment, because there are a lot of issues with walking between pages on launchpad for well-known reasons, and I’m not sure network packet loss, blocking, etc. doesn’t affect registering GPG keys.

But I don’t want to waste any more energy on it.

As a Workaround, you create GPG keys on your own host, and you can continue to create child keys. You will then export your master key (private key + public key), not the subkey, and import the exported key to the Ubuntu system to complete the signature.

The environment variable

For deb builds, we add environment variables to.bashrc:

DEBEMAIL="[email protected]"
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
Copy the code

Please modify the variable values yourself.

Launchpad account

PPA is a package distribution channel provided by Launchpad.net. So you must first visit launchpad.net/+login to get a Launchpad account.

What you need to know is that Launchpad.net is run by Canonical, and Ubuntu.com is run by their family, so the Launchpad account is essentially an Ubuntu One account, and the group of sites is a family.

The application link therefore redirects to the Ubuntu One registration page.

Note that the email address used for the account application must be the same as that used for the GPG Key.

Without further ado, after signing up for an account, first make sure your email address is valid and then add your SSH, GPG Key to your user centric page. Assuming you have an account with the username hedzr, your page is at launchpad.net/~hedzr. Add SSH Key and GPG Key to the corresponding entry, and your page should look something like the following:

The link to add OpenPGP keys is launchpad.net/~hedzr/+edi…

Add SSH keys link to launchpad.net/~hedzr/+edi…

Create a PPA

Now you can Create your first PPA using the link Create a new PPA.

This step is very simple, there will be no domestic characteristics, straightforward can be done.

There is no obvious limit to the number of PPA you can create, and each PPA typically has 2GB of capacity. So we ask you to first create a PPA named test-PPA to do the following.

A created PPA has a unique identifier such as PPA :< username >/< ppA-name >, and users will add your PPA using this syntax:

sudo apt-add-repository ppa:hedzr/test-ppa
Copy the code

Replace the necessary fields yourself.

Release your first software package

We already know that deb builds in two ways:

  1. Build deb from binary package:

    • Create a deb file From Scratch

  2. Build deb from source package:

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

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

Prepare the source code

In Ubuntu, we started publishing at $HOME.

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

Working directory

The first step is to create a working directory:

mkdir -pv ~/deb/testpackage.work/testpackage
cd ~/deb/testpackage.work/testpackage
Copy the code
  1. We’re going to do multiple things, so basically deb/;
  2. . Deb building are output to the source package directory at the next higher level, so we use testpackage. Work/testpackage two-level directory structure to place the source file
  3. In the future, the.deb file will be printed to testpackage.work/.

C source code main.c

And create a main.c in place:

cat > main.c <<EOF #include 
      
        int main() { printf("Hello world! \n"); } EOF
      
Copy the code

The C project builds the Makefile

Then there is the Makefile. This Makefile must have two Targets: all and install.

Only install is actually required, and make’s default target must be able to build binary results and be used correctly by Install.

Makefiles are 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}/

Copy the code

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
Copy the code

Note that to ensure that the Makefile is formatted correctly (each target’s command sequence must be indented with the TAB character), we use echo -e and explicitly use the \ T escape character to express the indentation.

You can try building in the working directory:

make all
Copy the code

We already know that the PPA server uses the build server to build the source package we uploaded, and ${DESTDIR} is set to a local value by the build server. But it usually doesn’t specify a value for our native build or for users building via apt Install.

${BINDIR} is preset to the value /usr/bin, which is the default destination for our installed package executables.

Create source information and control files for a package based on the source package

C source code is very simple, now we need to create a Debian folder and a set of control files:

Dh_make -p testPackage_0.0.1 --single --native --copyright Apache --email$DEBEMAIL
Copy the code

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

Version number: should be 4 sections, usually used in the first three sections, the last section is only used when releasing emergency patches, also refer to semver and the new Debian Maintainer manual.

For deb’s source package build, it uses a Debian folder to hold the control files deb needs for packaging.

This is different from the DEBIAN folder in the Binary Package.

Dh_make will ask you a number of questions, and when you have answered them you will find a series of files in the Debian folder. Ex is optional, such as postinst.ex. If you want to write a Postinst script, you can rename it postinst. This file already has the necessary skeleton, so you can focus on your logic. But if you don’t need to write a postinst script, postinst.ex can be safely removed:

rm debian/*.{ex,EX}
Copy the code

After dh_make is run, the generated files are in Debian / :

Review control document

debian/README*

These files provide documentation descriptions that you can modify to express the purpose of your package.

debian/changelog

The most important file in which you need to add the description of the new version every time you upgrade. Upload and publish cannot complete successfully without the correct new version description information section.

We need to revise this document:

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

Because what we need is an installation package for a specific Ubuntu version (20.04 in this case), we won’t touch multiarch or any mode for now.

Now it says something like this, where unstable has been replaced with focal:

Testpackage (0.0.0.1) focal; urgency=medium * Initial Release. -- hedzr <[email protected]> Tue, 07 Dec 2021 09:36:35 +0000Copy the code

This document is further elaborated in the upgrade section below.

debian/control

Also important, this file will be refactored into DEBIAN/ Control at Debuild time.

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

The control we just generated needs to be modified a little bit, usually involving fields like Section, Homepage, VC-Browser, VC-git, Description, and so on. 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) <[email protected]> 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!
Copy the code

The Description field can be multi-line and must be the last field. The first line of multi-line text must be indent with at least one space.

debian/rules

Rules is probably the most important file in the Source Package build because it gives you the opportunity to customize and modify the standard build behavior.

Rules will not be described in detail in this article because it is a huge topic that challenges individuals. We use the default generated version without making 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)

Copy the code

We will make some modest adjustments to this file in the next feature article, which will cover some of them. If you’re interested, don’t wait for our introductory series of articles, just head over to the New Debian Maintainer manual.

More…

You can go through the other documents in turn and make revisions as needed. But as a software package for the first experimental purpose, that’s it.

You can add postinst, postrm, etc. There is no extra difference, so you can refer to creating a deb file From Scratch – Create. Deb From Scratch, as well as MaintainerScripts.

Note that DH_make already generated the full template for these files for us, except that they end with the.ex suffix, so when you want your own version, simply rename these skeleton files.

Sometimes you need to double-check the executable permissions of these script files to make sure they are at least 0755.

Let’s push on to the next step.

Build distributable packages

Build deBs and sign them with our proprietary Subkey.

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

-s indicates build from source code.

– US-UC specifies the signing option;

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. ChangesCopy the code

Upload to our PPA

Testpackage_0.0.1_source. changes is the information file required to upload, and 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
Copy the code

It is equivalent to:

Dput ppa: hedzr/testppa testpackage_0. 0.0.1 _source) changesCopy the code

Problems that may occur

gpg.errors.BadSignatures

If your GPG Key has several subkeys, this signature will not be correct and dput will fail to validate the package file before uploading.

$ dput ppa:hedzr/test-ppa .. / testPackage_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.3 ubuntu1'.'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
Copy the code

The upload is not completed at this time.

Ignore the signature to see more

Unchecked, if you wish

Dput - unchecked ppa: hedzr/testppa testpackage_0. 0.0.1 _source) changesCopy the code

Askubuntu.com/questions/8…

The rest of the upload process is displayed:

$ dput -f -u ppa:hedzr/test-ppa .. Changes to ppa (via FTP to ppa.launchpad.net): Uploading testPackage_0.0.1. DSC:doneThe Uploading testpackage_0. 0.0.1. Tar. Xz:doneThe Uploading testpackage_0. 0.0.1 _source. Buildinfo:doneThe Uploading testpackage_0. 0.0.1 _source. Changes:done.
Successfully uploaded packages.
Copy the code

But that’s not true. Dput works in dry-run mode.

To solve the problem

The solution is to edit your GPG Key, remove all subkeys and keep only the primary Key:

$ gpg --edit-key 17AFB9B1
key 2
delkey
key 1
delkey
save
Copy the code

Suppose you have two subkeys. The command sequence above locates each subkey in turn, deletes them, and finally saves and exits.

In order to comply with Launchpad’s restrictions, they can only register your primary key and only verify with your primary key.

Now remove the wrong package and repackage it:

$ rm .. /testpackage_* $ debuild -S -k$DEBSIGN_KEYID| tee /tmp/debuild.log 2>&1 $ dput ppa:hedzr/test-ppa .. Changes to ppa (via FTP to ppa.launchpad.net): Uploading testPackage_0.0.1. DSC:doneThe Uploading testpackage_0. 0.0.1. Tar. Xz:doneThe Uploading testpackage_0. 0.0.1 _source. Buildinfo:doneThe Uploading testpackage_0. 0.0.1 _source. Changes:done.
Successfully uploaded packages.
Copy the code

A few minutes later, you’ll get an email from Launchpad saying they’ve accepted the package we just uploaded,

Now you can install it from your personal PPA:

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

Notice that we built a TARball in XZ format, not a DEB file. But that difference doesn’t really matter, because the properties are the same. Also, remember that deb is just a bundle of control file xZ packages and content file XZ packages (in AR format), so there’s really no difference.

Tackle the problem at source

The server used for packaging is usually not your main machine, so the GPG keyrings on this server are actually built by importing your GPG private key file.

This can be used when you export the private key on the main machine! Export only the specified key, not the subkeys:

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

This way, after the server imports, there is only the master key.

Similarly in some other places also have the same need to specify precisely rather than the best match of the situation, can be used! Suffix method.

Error: signing key fingerprint does not exist

When I first tried testPackage, I could understand your urgency, because I felt the same way. But the truth is, you need to be patient, you won’t see a launchpad PPA status update immediately after a successful upload from local, you won’t get an email immediately, especially if your package is huge and time-consuming to build. B: Don’t worry, it will.

Also, if you get an email and want to try the install test soon, then you might get an error where the key doesn’t 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.
Copy the code

BE PATIENT. Launchpad actually needs to create a new GPG Key for your PPA, which takes a little bit of time to upload to keyserver.ubuntu.com and a little bit of time to complete synchronization and distribution in the pool, so wait, Retry, you won’t be here for long.

Other information

Launchpad PPA for You

If you’re even a little curious about this new key, check it out:

$ apt-key list <Your_launchpad_username>
Copy the code

Such as:

$ 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
Copy the code

Verify the testPackage information

Check the package information
apt info testpackage

Display the files in the package
dpkg -L testpackage

Copy the code

Install TestPackage as a consumer

In the user’s 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
Copy the code

Upgrade to a new version

When you are ready to release the next release, just revise Debian/Changelog for debian control files. A sample would look something like this:

Testpackage (0.0.0.2) focal; urgency=medium * Updated: fixed build errorin sourceCodes -- Hedzr <[email protected]> Tue, 08 Dec 2021 09:28:35 +0000 TestPackage (0.0.0.1) focal; urgency=medium * Initial Release. -- hedzr <[email protected]> Tue, 07 Dec 2021 09:36:35 +0000Copy the code

You can modify the Changelog file with DCH -I or DCH -V version-revision.

Next is the rebuild:

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

A new version will now be 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.2_source. build-rw-r --r-- 1 Hz Hz 6199 Dec 8 01:29.. / testPackage_0.0.2_source.buildinfo -rw-r--r-- 1 Hz Hz 2033 Dec 8 01:29.. / testpackage_0 hundreds _source. ChangesCopy the code

Then you will upload it to the PPA:

$ dput ppa:hedzr/test-ppa .. / testPackage_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.2. DSC: Valid Signature from 2E6F77F217AFB9B1 Uploading to PPA (via FTP to ppa.launchpad.net): Uploading testpackage_0. Hundreds. DSC:doneThe Uploading testpackage_0. Hundreds. Tar. Xz:doneThe Uploading testpackage_0. Hundreds _source. Buildinfo:doneThe Uploading testpackage_0. Hundreds _source. Changes:done.
Successfully uploaded packages.

Copy the code

Be patient, a new version will be released.

Check the release status on the PPA

For HEDZR/test-PPA, see here: launchpad.net/~hedzr/+arc…

Each package name can be expanded and releases of Builds that fail have a link to buildlog to see why they fail.

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

Bonus

When your package is stable enough and useful enough to be in the official PPA, or even in the official source, having a package of the same name installed in your personal PPA is a bit out of place.

The PPA-Purge program makes it easy for users to purge packages installed from your personal PPA and install and replace them with a package of the same name from the official ppa source. Of course, if there is no official version of the same name in the official source, the package will remain unchanged.

sudo ppa-purge ppa:<lp-name>/<ppa-name>
Copy the code

The end of the

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 sources of learning for this article was very much this one.

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

However, read it, there is no need to rush to intensive reading it, but with the help of this article directly start to run again, their own run out of an example, and then go back to intensive reading is more appropriate.

Debian Policy Manual is a very important reference Manual. For Chinese people, you need to face the fact that there is no Chinese translation version of it, but its grammar is very simple, and it is estimated to be difficult for a 5 or 6 year old child to read. All you need is a certain amount of computer vocabulary. All of the Debian /* files we mentioned, including those mentioned in the new Maintainer’s handbook, are detailed in the Policy manual, which you will have to refer to if you want to write your own further control files.

I’ve found that you can do things if you set your mind to them. I’ve been avoiding further research or learning from the Packaging side of things, instead using easier ways to do distribution (such as releasing it on GitHub and releasing it to you), but simplicity probably means user inconvenience. That’s where I ended up having to go professional Packaging. But with some research, it’s easy to see that some resources are out there, but no one is trying to tell you where something is. What to do? Generally speaking, find a professional newsgroup such as USNET, and the probability of getting useful instructions when asking questions is higher. But consumer-facing sites like Quora are not necessarily good choices. I must note that Discord or Dev. to isn’t very helpful in dealing with the details of Packaging that I’ve covered. Eventually, of course, you’ll have to turn to Google to find the channels I’m talking about, including useful blog posts. In the same way, mine, I think, would be useful for someone to actually get to the point.

reference

  • Debian new Maintainer handbook
  • 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: