On 22/11/23 15:37, John Thacker wrote:
On Wed, Nov 22, 2023 at
9:40 AM João Valverde <
j@xxxxxx>
wrote:
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.
Thanks for the feedback. Let me try to break down my response to
that:
1. I think spending resources on distro packaging is unwise in
general. "Make install" works fine and there are great maintainers
already doing that work for Linux distributions. RPM is just
low-effort low-intrusion enough that it doesn't bother me to divert
from other tasks to work on it when I have to.
2. Debian is especially ill-suited for end-users building locally.
The recommended way to have a stable system without broken
dependencies is to create a local APT repository. Anything else is
asking for trouble.
3. Our Debian package is particularly unfriendly to the
user-wants-to-build-locally use-case. I could maybe see providing a
basic .deb package but why are we syncing changes from downstream
with 5 different binary packages and loads of Debian policy baggage?
It's a very unique situation and I fail to see any benefit for
end-users or Wireshark developers. Maybe the reason is that we would
like to be the best upstream possible for Debian. It's a reason at
least.
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
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe