lathiat
Document in 0.9 release notes, which parts/bindings are obsolete/going away
Following the discussion in https://github.com/lathiat/avahi/pull/509#issuecomment-1792528401 I'd like to see documented in the release notes of 0.9, which parts/bindings are declared obsolete and scheduled to be removed by a subsequent release. Candidates for the chopping list:
- Qt3/Qt4 bindings (avahi-qt/) #509
- mono bindings (avahi-sharp/ , avahi-ui-sharp/)
- gtk2.0 bindings (avahi-ui/)
- HOWL compatibility layer (avahi-compat-howl/) https://github.com/lathiat/avahi/pull/531
- ...
Do we know the maintainers of Avahi in OpenSUSE, Arch, $your_favourite_distro, we could ping regarding this matter?
I'd EOL avahi-compat-libdns_sd and avahi-compat-howl. https://avahi.org/doxygen/html/ already says
Please note that these compatibility layers are incomplete and generally a waste of resources
Plus they have come with banners saying
*** WARNING: The application '%s' uses the "COMPAT_LAYER" compatiblity layer of Avahi. Please fix your application to use the native API of Avahi!
since 2005 but bug reports like https://github.com/lathiat/avahi/issues/479 and PRs like https://github.com/lathiat/avahi/pull/465 are still opened in 2023. I'm not sure they should be removed from the repository completely but I think they should be officially deprecated, issues and PRs should be closed and they should just be frozen.
Unfortunately I don't know who maintains avahi on distros other than Debian and Fedora/RH but I believe Debian and Fedora/RH are enough to get the ball rolling.
@evverx We use avahi-compat-libdns_sd, so I would appreciate it if it remained in the project.
@nkarstens got it. Based on issues I've seen here on GitHub it's indeed used and that's why I don't think it should be just dropped. The idea is to somewhat show that it isn't maintained (upstream at least). My understanding that you carry patches fixing various avahi bugs and deprecating the compat lib but keeping it shouldn't break a lot of things hopefully.
I'll add the "needs-discussion" label just to make it clear that nothing has been set in stone yet. It's just my opinion after all. Then again looking at, for example, https://github.com/lathiat/avahi/issues/467 (unrelated to the compat libs) it seems to me that the "help wanted" label is overly optimistic. That part isn't tested at all: https://coveralls.io/builds/63727427 (and personally I'm not planning to change that), small changes like https://github.com/lathiat/avahi/pull/462 turn out to break other set-ups and so on. I think things like that should be just left alone to save contributors/bug reporters/maintainers time.
Regarding avahi-compat-libdns_sd, we do actually have reverse dependencies in Debian:
$ dak rm -Rnb libavahi-compat-libdnssd1 libavahi-compat-libdnssd-dev
Will remove the following packages from unstable:
libavahi-compat-libdnssd-dev | 0.8-12 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x
libavahi-compat-libdnssd1 | 0.8-12 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x
Maintainer: Utopia Maintenance Team <[email protected]>
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
aseba: aseba [amd64 arm64 i386 mips64el riscv64]
barrier: barrier
belle-sip: libbellesip2
mumble: mumble
mumble-server
pike8.0: pike8.0-dnssd
uxplay: uxplay
# Broken Build-Depends:
aseba: libavahi-compat-libdnssd-dev
barrier: libavahi-compat-libdnssd-dev
belle-sip: libavahi-compat-libdnssd-dev
mumble: libavahi-compat-libdnssd-dev
pike8.0: libavahi-compat-libdnssd-dev
shairplay: libavahi-compat-libdnssd-dev
uxplay: libavahi-compat-libdnssd-dev
Dependency problem found.
If it works for them it should probably be fine to keep shipping it. The question is what happens when they run into things like https://github.com/lathiat/avahi/issues/98. They report it to Debian, Debian forwards it upstream and that's it. It's unlikely to ever be fixed. When patches are sent to fix other bugs they can introduce new bugs that are worse: https://github.com/lathiat/avahi/pull/17 and there aren't enough tests to be confident in anything really. If it was marked "deprecated" or something like that it would set realistic expectations.
In NixOS, we have the following packages depending on avahi-compat-libdns_sd:
barrierbrscan5fx-cast-bridgehaskellPackages.dnssdthis is an automatically packaged Haskell library, it does not appear anything in Nixpkgs uses itinput-leapmumblemurmurpixinsightrpiplayshairplaysynergyuxplay
Ideally, we would ask the projects to switch to the native avahi API but it looks like many of them target MacOS in addition to Linux so they might be reluctant to switch because it would require them to support two different libraries.
Our avahi package does not support any other features suggested for deprecation.
Additionally, I would like to suggests avahi-ui for removal. The only thing that depends on it in Nixpkgs is libepc (and only for examples), and libepc itself is only used by glom, both of which are unmaintained upstream.
GNOME platform is moving away from GTK 3 and for modern GTK apps, it is often preferable for libraries to just provide GListModels and let apps materialize the data according to their needs – see libpeas, gcr or ligweather for an example.
The utilities found in avahi-ui (bshell/bssh/bvnc) are packaged in Debian as avahi-ui-utils. This package does not have any reverse dependencies. The gtk3 bindings seem to be used though:
$ dak rm -Rnb libavahi-ui-gtk3-0 libavahi-ui-gtk3-dev
Will remove the following packages from unstable:
libavahi-ui-gtk3-0 | 0.8-12 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x
libavahi-ui-gtk3-dev | 0.8-12 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x
Maintainer: Utopia Maintenance Team <[email protected]>
------------------- Reason -------------------
----------------------------------------------
Checking reverse dependencies...
# Broken Depends:
avahi: avahi-ui-utils
remmina: remmina
vinagre: vinagre
# Broken Build-Depends:
glom: libavahi-ui-gtk3-dev
libepc: libavahi-ui-gtk3-dev (0.6.22 >=)
remmina: libavahi-ui-gtk3-dev (0.6.0 >=)
vinagre: libavahi-ui-gtk3-dev (0.6.26 >=)
Dependency problem found.
Yes, avahi-ui-utils would be dropped as well.
And I do not think any of those other reverse dependencies should be a blocker:
- Remmina is slowly transitioning towards GTK 4 so avahi-ui-gtk3 will be pointless for it.
- Glom does not depend on avahi-ui since 2010.
- libepc is abandoned and only needs it for examples that are not even installed. The build script lists it as a hard dependency but it can easily be patched out: https://github.com/NixOS/nixpkgs/pull/265534
- Of the above, Vinagre is only lasting user but it is also abandoned and was superseded by GNOME Connections, and since avahi-ui dependency is optional, I would just disregard it.
@jtojnar thanks a lot! It's a lot to process.
Having read this thread I think avahi-compat-libdns_sd should be excluded from this discussion. I have to admit I have no idea how to proceed with it but deprecating it and stopping accepting patches would probably be the wrong thing to do.
Regarding avahi-ui to judge from https://github.com/lathiat/avahi/issues/443 (which was reported relatively recently) it appears at least bssh is used. I don't think it's used often but I'd wait for at least a reply there.
Also yesterday I came across https://github.com/lathiat/avahi/issues/274 and took a look at the "initscript" folder. Fedora, openSUSE and Debian drop those scripts when avahi is packaged so I think they can be removed right now. (I'm not 100% sure about Debian though because its derivatives can in theory use them but I took a look at one distro where I thought they would be kept but it appears to blindly take the Debian package and drop them as well. @mbiebl are you OK with dropping those scripts?) Those scripts produce a gazillion shellcheck warnings and I'm not happy about it :-)
The suse and fedora init scripts were removed in https://github.com/lathiat/avahi/commit/96f9e48fde435bed7c8489f09bef9b9b2c4fc422 and https://github.com/lathiat/avahi/commit/4630fbeea672a7be70a1fc5b2f47c418b1981cc6. I'll let Debian decide what to do with the debian scripts.
I've updated the list to include https://github.com/lathiat/avahi/pull/531 dropping the HOWL compat layer.
Would appreciate input from other distros.
That's kind of controversial.
Would appreciate input from other distros
I'm not sure all of them here on GitHub. The mailing list (https://lists.freedesktop.org/mailman/listinfo/avahi) was resurrected lately but I don't know if any maintainers are subscribed to it.
@thesamesam sorry to bother you but looking at https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/avahi/avahi-0.8-r7.ebuild it seems the Gentoo package ships some things discussed here and even though it doesn't seem to be actively maintained it would be great if the Gentoo folks could join the discussion (to avoid any unexpected breakages).
In OpenEmbedded/Yocto by default we disable most of the UI addons and let users enable them if needed. I'd much prefer a leaner core avahi which was just the daemon and fundamental libraries, and then separate projects for gtk/qt/etc that can be created/deprecated/obsoleted easily without the core needing to care.
In OpenEmbedded/Yocto by default we disable most of the UI addons and let users enable them if needed
Just to make sure if all the things discussed here were removed from the avahi repository would it affect OpenEmbedded/Yocto in any way?
I was kind of hoping OpenEmbedded doesn't build autoipd but looking at https://github.com/openembedded/openembedded/blob/master/recipes/avahi/avahi.inc it seems it's there.
(Also it appears --with-distro=debian is passed there and *init.d* is included in FILES_avahi-daemon and https://github.com/lathiat/avahi/commit/215f00b667e6f14434c33327b24f28816fda861c kind of breaks all that. Would it be possible for OpenEmbedded to keep those files downstream? I'm not sure those untested scripts with 50 or so shellcheck warnings should be brought back)
Just to make sure if all the things discussed here were removed from the avahi repository would it affect OpenEmbedded/Yocto in any way?
Well it would affect us, but I'd prefer modular avahi-foo projects instead of a single monolithic avahi with lots of options, so I'd say it would affect us for the better.
As we're source-based and the assumption is that users are going to be customising anyway we worry slightly less about migration paths than other distros.
I was kind of hoping OpenEmbedded doesn't build autoipd but looking at https://github.com/openembedded/openembedded/blob/master/recipes/avahi/avahi.inc it seems it's there.
Packaged into a separate package, not referenced in other layers I have to hand, so quite possibly never actually used.
(Also it appears
--with-distro=debianis passed there and*init.d*is included inFILES_avahi-daemonand 215f00b kind of breaks all that. Would it be possible for OpenEmbedded to keep those files downstream? I'm not sure those untested scripts with 50 or so shellcheck warnings should be brought back)
Yeah that's not a problem, we patch them anyway.
I'd prefer modular avahi-foo projects instead of a single monolithic avahi with lots of options
The idea is to remove some components completely and figure out what to do with the other parts that can't be removed for whatever reason. Even though they aren't maintained they can at least benefit from the CI (for example compilers compile-tested some PRs, ASan caught a write-use-after-free in the dns_sd compat lib, Coverity reported a bunch of issues there, the coverage report shows how good/bad things are and so on). I seriously doubt they are going to be even compile-tested anywhere if they are split.