Not a full answer, but may help.
If the executable will have this capability, then you should make it only executable by a certain group (to prevent random users from grabbing the port).
If you are creating a new program, then you should make it capability aware (use capability system calls, to move capabilities in and out of the effective set). So no need ...
Please update your post/title as there is no mention about a reboot in post
To start app immediately after install You can try using
$ sudo apt install my_app ; my_app
That will first install that app, and after that execute it.
You seem to have installed a newer version of mock provided by EPEL.
For that package, the config files are changed from /etc/mock/centos-7-x86_64.cfg to /etc/mock/epel-7-x86_64.cfg and are provided by the RPM package mock-core-configs.
The newer mock seems to be for the transition to dnf and python3, so they may have removed architectures that they no ...
You can check SUSE Open Build Service (OBS). It supports deb packages builds. Some useful links:
You wouldn’t manually place them anywhere. Assuming they’re included in the upstream tarball you use, they will be extracted during the build, and the %check part will use the extracted tests.
SOURCES contains the downloaded files corresponding to Source: stanzas in your .spec file. The various directories are used as follows, in this order:
SPECS contains ...
I’m guessing your source package builds a single binary package; i.e., your debian/control has a single Package: stanza. In such situations, dh_auto_install installs files to debian/package, and the assumption then is that that is sufficient, i.e. all the files you need to install end up in the right place under debian/package once dh_auto_install completes.