Github messages for voidlinux
 help / color / mirror / Atom feed
* [ISSUE] RFC: avahi-stub possible?
@ 2020-05-28 20:20 pullmoll
  2020-05-28 23:19 ` Chocimier
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: pullmoll @ 2020-05-28 20:20 UTC (permalink / raw)
  To: ml

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
@ 2020-05-28 23:19 ` Chocimier
  2020-05-28 23:46 ` ericonr
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Chocimier @ 2020-05-28 23:19 UTC (permalink / raw)
  To: ml

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
  2020-05-28 23:19 ` Chocimier
@ 2020-05-28 23:46 ` ericonr
  2020-05-29  9:27 ` pullmoll
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ericonr @ 2020-05-28 23:46 UTC (permalink / raw)
  To: ml

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
  2020-05-28 23:19 ` Chocimier
  2020-05-28 23:46 ` ericonr
@ 2020-05-29  9:27 ` pullmoll
  2020-05-29  9:47 ` Chocimier
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pullmoll @ 2020-05-29  9:27 UTC (permalink / raw)
  To: ml

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
                   ` (2 preceding siblings ...)
  2020-05-29  9:27 ` pullmoll
@ 2020-05-29  9:47 ` Chocimier
  2020-05-29 10:13 ` pullmoll
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Chocimier @ 2020-05-29  9:47 UTC (permalink / raw)
  To: ml

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
                   ` (3 preceding siblings ...)
  2020-05-29  9:47 ` Chocimier
@ 2020-05-29 10:13 ` pullmoll
  2020-05-29 12:08 ` Johnnynator
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pullmoll @ 2020-05-29 10:13 UTC (permalink / raw)
  To: ml

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
                   ` (4 preceding siblings ...)
  2020-05-29 10:13 ` pullmoll
@ 2020-05-29 12:08 ` Johnnynator
  2020-05-30  2:31 ` ahesford
  2020-05-31 15:39 ` [ISSUE] [CLOSED] " pullmoll
  7 siblings, 0 replies; 9+ messages in thread
From: Johnnynator @ 2020-05-29 12:08 UTC (permalink / raw)
  To: ml

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
                   ` (5 preceding siblings ...)
  2020-05-29 12:08 ` Johnnynator
@ 2020-05-30  2:31 ` ahesford
  2020-05-31 15:39 ` [ISSUE] [CLOSED] " pullmoll
  7 siblings, 0 replies; 9+ messages in thread
From: ahesford @ 2020-05-30  2:31 UTC (permalink / raw)
  To: ml

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ISSUE] [CLOSED] RFC: avahi-stub possible?
  2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
                   ` (6 preceding siblings ...)
  2020-05-30  2:31 ` ahesford
@ 2020-05-31 15:39 ` pullmoll
  7 siblings, 0 replies; 9+ messages in thread
From: pullmoll @ 2020-05-31 15:39 UTC (permalink / raw)
  To: ml

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-05-31 15:39 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-28 20:20 [ISSUE] RFC: avahi-stub possible? pullmoll
2020-05-28 23:19 ` Chocimier
2020-05-28 23:46 ` ericonr
2020-05-29  9:27 ` pullmoll
2020-05-29  9:47 ` Chocimier
2020-05-29 10:13 ` pullmoll
2020-05-29 12:08 ` Johnnynator
2020-05-30  2:31 ` ahesford
2020-05-31 15:39 ` [ISSUE] [CLOSED] " pullmoll

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).