[Bálint Réczey <balint@xxxxxxxxxxxxxxx>]

Hi,

João Valverde <j@xxxxxx> ezt írta (időpont: 2023. nov. 27., H, 21:42):
>
>
>
> 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.

I tried to assess the amount of work required by the presence of the
Debian packaging scripts in the repository.
This is what I found covering roughly one year of development in the
master branch between branching off the 4.0 and 4.2 releases:

$ git merge-base origin/release-4.2 origin/master | xargs git describe
v4.1.1rc0-386-geb539196a9
$ git merge-base origin/release-4.2 origin/release-4.0  | xargs git describe
v3.7.3rc0-146-g7d583e1340
$ git log --oneline v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 | wc -l
3925
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
packaging/debian/ | wc -l
64
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 --
packaging/debian/*.symbols | wc -l
50

1.6% of all the commits touched the packaging scripts. Most of the
1.6% is updating the symbols files when the shared library ABI changed
and I did not consider that excessive, but seeing the complaints I've
switched the packaging to not require symbols file updates in
https://gitlab.com/wireshark/wireshark/-/merge_requests/13385 .

The remaining Debian packaging script 14 updates accidentally matches
the number of updates to the RPM scripts and makes up 0.3% of all
Wireshark commits in the analyzed history:
$ git log --oneline
v3.7.3rc0-146-g7d583e1340..v4.1.1rc0-386-geb539196a9 -- packaging/rpm/
| wc -l
14

I hope with the symbols file overhead removed the maintenance of the
scripts will be well worth it for the benefit of the users relying on
it.
I will try to be more responsive as well. If there is a pressing issue
that I did not notice on GitLab, please ping me in email.

> 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.

I think in the previous point I showed that with the symbols file
updates eliminated very few developers will need to touch the Debian
packaging.
Regarding the separate library packages the official Debian packaging
is structured like this since 2010:
http://snapshot.debian.org/package/wireshark/1.4.0~rc2-1/#libwiretap0_1.4.0:7e:rc2-1

Having separate packages follows Debian packaging best practices and
served external projects extending wireshark such as netexpect (
https://tracker.debian.org/news/505793/accepted-netexpect-018-1-source-i386/
) and the separately maintained libvirt dissector (
https://packages.debian.org/unstable/libvirt-wireshark ).

As I interpret our Code of Conduct collaboration with other projects
is highly encouraged no matter if Wireshark builds on them or they
build on Wireshark. I acted according to that in maintaining the
Debian packaging both here and in the official Debian repository.

Why can't we have a different packaging layout here? - one may ask.
The problem with that is not apparent from first sight, but can
surface months or years later. Dpkg, the Debian package manager tries
very hard to avoid accidental file overwrites and if files move across
packages and the moves are not declared in the packaging control files
it breaks the package installation. This can occur in the middle of a
full distribution upgrade and if a dist-upgrade fails it is usually
tricky to recover from it.
If self-made .deb packages can be built from wireshark's sources the
generated .debs should not break the system later. Now this is ensured
by having the same packaging layout, thus official and self made
Wireshark packages are interchangeable, upgrades are smooth migrating
either way.
To decrease the number of packages built I've merged wireshark-qt to
wireshark in sync with the official packages:
https://gitlab.com/wireshark/wireshark/-/merge_requests/13423
I see that installing multiple packages is a bit less convenient than
installing one, but I think running

 sudo apt install ./*.deb
 in the dir where the packages are generated is not too hard either.

Cheers,
Balint