[ISSUE] RFC: avahi-stub possible?

[ISSUE] RFC: avahi-stub possible?

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

New issue by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/22389

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

Re: RFC: avahi-stub possible?

[Chocimier]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

New comment by Chocimier on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-635666926

Comment:
Separating build of subpackages depending on qt and gtk like https://github.com/void-linux/void-packages/pull/21974 breaks cycles as well. 

Re: RFC: avahi-stub possible?

[ericonr]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-635675275

Comment:
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).

Re: RFC: avahi-stub possible?

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-635873529

Comment:
@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.

Re: RFC: avahi-stub possible?

[Chocimier]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

New comment by Chocimier on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-635882100

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

Re: RFC: avahi-stub possible?

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

New comment by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-635893250

Comment:
@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.

Re: RFC: avahi-stub possible?

[Johnnynator]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

New comment by Johnnynator on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-635937250

Comment:
The build cycle was added in #21731 and for now reverted in 6c2e984eb77c00f048a24d73d1ebadaf312f92dd

Re: RFC: avahi-stub possible?

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/22389#issuecomment-636263242

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

Re: [ISSUE] [CLOSED] RFC: avahi-stub possible?

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

Closed issue by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/22389

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