Did that. Ran an internal APT server for years. Was a fantastic system for doing remote installs on field installations.
Like, you create a folder structure that mimics the final installation inside one of the two toplevel deb folders. The other folder had a manifest or two. Worked easy, and did not take long to figure out
In that src file are things like "usr/whatver", "opt/whatever", "etc/whatever" and "DEBIAN"
In DEBIAN is a really simply control file and sometimes some scripts to do things on install.
Getting a package approved by the debian maintainers is an issue if you don't follow the guidelines (and lintian will help) - just like getting a package approved by the redhat maintainers, but to make your own deb is barely harder than creating a tarball.
That's why I qualified it "according to packaging guidelines".
And I don't want to comply with packaging guidelines because I want to get it into the upstream repo; no, I want it compliant so it is not broken at upgrade time and I don't want to have to solve several problems at once at the most inconvenient time.
With rpm it is both easy and piecemeal - you don't have to have the entire knowledge in your head upright, you can improve it continuosly. You start with spec file and rpmbuild, then find out about rpmlint, then you will find out about mock (so you can build package for Fedora-any version and CentOS-anyversion from any distribution, including Ubuntu or Debian, inside chroot or container) to koji (full blown distro-scale build system).
Like, you create a folder structure that mimics the final installation inside one of the two toplevel deb folders. The other folder had a manifest or two. Worked easy, and did not take long to figure out
https://blog.knoldus.com/create-a-debian-package-using-dpkg-...