RFC: avahi-stub possible?

[pullmoll]

This is a request for comments for an idea which came to me when I had to deal with the inevitable mess of dependency cycles which avahi creates by its sole appearance in package's makedepends.

The idea is basically to invent an avahi-stub package which implements the interface(s) of avahi-libs-devel but, instead of depending on everything that avahi depends upon, depends on nothing else.

The stub library (or libraries) would then, at runtime, try to dlopen(3) the actual libavahi-client.so.3, libavahi-common.so.3, and libavahi-core.so.7 libraries and resolve their functions to store them in the stub's function pointers.

If a user (like me) chose not to install avahi at all, these functions pointers would be NULL and the stub functions would return the corresponding error codes and perhaps set errno = ENOSYS or whatever.

If OTOH the avahi package is installed, the stub would resolve the functions and then forward to them, adding one layer of call/return.

I don't know if anyone else already tried such a thing, whether it is at all possible, or if there are reasons why this cannot work in principle, that's why I ask here.

I'd love to be able to bootstrap and build up a Void repository without taking hours or days of manually tuning the package building process to avoid avahi here and pulseaudio there when building temporary packages to resolve the depedency cycles ... etc. pp.

Should this idea work, every package now depending on avahi-libs-devel would then depend on avahi-stub-devel and the bootstrap and repository build-up should work without human intervention.

[Chocimier]

Separating build of subpackages depending on qt and gtk like #21974 breaks cycles as well.

[ericonr]

Would we have to develop such a project? Mostly a fork but removing all function impls and using dlopen instead? (at least that's what I can think of).

[pullmoll]

@Chocimier this is of course possible. It requires additional effort on the side of the maintainer or anyone from the team. In case of e.g. pulseaudio or cups I'm not sure that separating avahi dependent submodules from the rest is possible.

@ericonr yes, we would have to write such a project. We would basically have a fork of avahi with all functionality stripped away and functions just forwarding to the real thing, if it was found, otherwise returning an error condition. I haven't seen something like this already being developed.

I would try to do that for avahi. I've done similar things with Windows DLLs e.g. to intercept all TWAIN API calls and log and debug them, so in theory I would know what to do. What I'm asking here is if someone sees elementary reasons why this would not work.

[Chocimier]

I was thinking of building avahi, avahi-libs, avahi-libs-devel from one template and avahi-qt5-libs, avahi-ui-libs from second template. I didn't try if it works, but would take less time that modifying all of cups, pulseaudio and so on, and possibly a bit less than forking avahi codebase. Of course, this only address bootstrap, not eliminating full avahi from resulting installed system.

[pullmoll]

@Chocimier this would also help! I guess you know what this is all about. It's not trying to get avahi eliminated from the system, but deferring its dependency tree impact. I'll perhaps try if this is workable as also to me it seems easier than creating an all new avahi-stub package.

[Johnnynator]

The build cycle was added in #21731 and for now reverted in 6c2e984

[ahesford]

PR #22406 returns to the earlier split behavior that I undid with the first 0.8 update. The original split template mentioned a desire to avoid gtk3 and gobject dependencies creeping into the base libs, but I overlooked the underlying build-cycle issue.

While the split doesn't help people install dependents without pulling in avahi libs, it at least eliminates the cycle problem.