There are a myriad issues I have touched upon. To recap, in my
opinion, if we want to provide public shared libraries
(libwireshark, wiretap, wsutil... for what I don't know) we should
do a better job of that collectively as a project. If we don't want
to do that we should kill the Debian package inanity.
A third alternative is just to keep the status quo and I'll try to
avoid this subject entirely because of how much it bothers me to
just ignore all these technical issues.
My understanding of the Debian packaging scripts (and similar for the RPM package) use case is that people might be running one of those distributions and want to upgrade Wireshark on their system using their distribution's native package manager by taking either a git repository or a tarball and building a package that they can upgrade their distribution-provided package to.
That isn't necessarily to add custom dissectors and provide public shared libraries, though it could be. Oftentimes it's as simple as "my distribution is capable of compiling 3.6.x or later, but for stability reasons it's still shipping 2.6.x (Debian buster/oldstable, RHEL 8 and clones)," and someone wants to update wireshark without any of their own changes, just without upgrading their distribution. It's handy to be able to accommodate that if possible.
I think moving the packaging assets to the packaging directory and telling people to symbolically link it to build Debian, as we've been doing, is a relatively minor imposition for the Debian folks, but my understanding is that the package builds will fail if all the Lintian stuff isn't done, which creates a burden on us.
On RPM distributions there's an annoyance because Red Hat / Fedora decided to change their package names around a bit, so they're no longer quite compatible with the old names which we provide (and which still work with other RPM-based distros -
https://gitlab.com/wireshark/wireshark/-/issues/18709 ).
John Thacker