Wireshark-dev: Re: [Wireshark-dev] Future of Wireshark's Debian packaging scripts in the main r

Date Prev · Date Next · Thread Prev · Thread Next
From: João Valverde <j@xxxxxx>
Date: Mon, 27 Nov 2023 20:42:26 +0000


On 27/11/23 16:26, Jeff Morriss wrote:
On Wed, Nov 22, 2023 at 11:54 AM João Valverde <j@xxxxxx> wrote:


    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.


I used to maintain a custom Wireshark build.  The packaging stuff was invaluable for that: it allowed me to compile (and easily package) once and push the resulting RPMs to hundreds of systems.  "make install" would not have worked for me as the end (user) systems were not capable of compiling Wireshark.

I also, for a while, used our RPM stuff as an upstream example for Fedora/Red Hat to improve their packaging, including (IIRC) bringing in all the freedesktop integration stuff.  It was a lot easier to check that stuff into Wireshark and point them to it than try to do all the work in their world/repo (which is unfamiliar to me).


I was addressing the user-wants-to-build-locally use case with the "make install" comment.

To address your use-case:

1. Someone whose job is to maintain a custom build for a medium/large organization does not depend on us to create a package, although it can help of course. At the end of the day resources are limited and need to be prioritized for a volunteer project. Like I said, RPM doesn't bother me, it rarely gets in my way or demands much of my time.

2. If someone on the Wireshark team wants to assume the package maintainer role that could work if they are responsive and not putting some distribution's priorities above our own.

3. Forcing every Wireshark developer to maintain the Debian package like the Debian maintainer thinks it should be maintained is definitely not fine in my opinion. Nobody so far has been able to offer any sort of technical explanation for packaging Wireshark's libraries separately, because there is no such rationale, other than Balint is really into that stuff.