At the moment, I get /usr/local/lib/libcapstone.so.6.0. My question is, where is the .so.6.0 being populated? Should a fix be made to have the files only be in a format like libcapstone.so.5, libcapstone.so.6, etc?

With that said, I will have to assume the version based as an argument is correct in populating the control file

I suspect I also need to update capstone.pc to point from /usr/local to /usr? Once again, the main question is how would the plan be to update these new packages to Ubuntu/Debian.

Should a fix be made to have the files only be in a format like libcapstone.so.5, libcapstone.so.6, etc?

You can check the Debian package naming conventions for details. The revision version must be part of the name apparently (docs, dpkg-name and more details).

I suspect I also need to update capstone.pc to point from /usr/local to /usr?

As I see it, it should install directly into /usr/lib (see: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html). So the current implementation (installing into /usr/local) is wrong. Can you please open another PR to fix it?

@AndrewQuijano I looked into your questions in detail and found actually more than one problem. I am sorry that I did not review more thoroughly before. I also never worked with deb packages until now, was in a rush due to other things and oversaw quite some problems.
Thank you for asking about these problems, otherwise I would have missed them.

The issues I found are the following:

• We didn't added all mandatory fields to the control file.
• Architecture in the control file was incorrectly set to all.
• As you already said, the package should be installed into /usr/.
• The generated package misses the dependency information.
• The package name was not according to the Debian standard.
• Hash sums missing

I tried fixing some of them, but quickly recognized that it gets out of hand quickly. And for Capstone we need a more complete approach.

As it looks like, the original script, you used as a basis, was never meant to generate a deb package for the official Debian/Ubuntu repositories. This would also explain why it was lacking so many things.

Unfortunately, we cannot provide a package which is this much incomplete for the release. In #2543 I removed it from the release CI, but kept your work in packages/deb/. Also you can trigger the package build by dispatching the new Build Debian Package workflow.

Because your initial idea was to ease the install in PANDA, I would see two solutions for this:

1. Fork the Capstone repository for PANDA and redo the package generation there. You can easily do a release in this fork and download the package for PANDA from it.
2. If you want to have a deb package in the official Ubuntu/Debian repositories, I would ask you to do the implementation from scratch. This time though by using CPack. And with CPack we can also generate packages for other distros. Also we have a certain guarantee that the built packages are correct.
   If you do so, please first submit the package to the Debian packages and wait for approval. Then we can merge it here.

I am sorry again I didn't properly reviewed the first PR, due to my lag of knowledge about Debian packages.