-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose almost all of libvarnish as libvarnishapi #3946
Comments
Hi @neufeind, Regarding your suggestion:
I understand that having to compile varnish-cache may be an inconvenience, but INSTALL.rst clearly mentions this requirement:
Note that besides |
In my eyes it was an "issue" or something that could be fixed in the varnish-devel packages. The readme imho suggests that it might compile on Debian with just the devel-packages (if I read right, can't test on Debian). So I thought it was something that could be improved by varnish-devel. The files are built when building varnish - they are just not packaged in the devel, or am I mistaken? If you say they aren't public API then that's possibly something that varnish and slack should negotiate how to address (if I may suggest). It would be great to have the slash-VMOD. Even greater if there were prebuilt packages :-) but at least being able to build them without rebuilding the varnish itself as well would help testing. |
May I suggest adding This way package maintainers aren't bothered by the optional dependency, only slash developers. |
@dridi I would want package maintainers to bundle As a follow up to this ticket, I had brief discussion with @bsdphk on IRC if the libvarnish/libvarnishapi separation was still justified: If we only had libvarnishapi, our installed binaries could shrink (IIUC by ~10%) because we could stop statically linking to libvarnish multiple times, of which most symbols are also already exposed by libvarnishapi (and all of libvarnish is linked into libvarnishapi as well). Time and time again, we extended the API, and I wonder how much we gain by not just having all libvarnish symbols in the public API - given that we were also not particularly strict about API stability. So, to be discussed: Should we
|
I'm not opposed to the idea of pruning
We probably also need to clean up certain things like VFIL, but I can probably dig up an old pull request of mine adding the missing bits for VFIL path to be usable outside of the VCC context. |
bugwash: we will inventory libvarnish APIs here and decide which ones go in libvarnishapi and which ones remain confined in libvarnish. We may create pull requests similar to #3956 for APIs that may require adjustments to become usable. |
@neufeind to give some context, quite surprisingly to me we actually ended up deciding that we will expose almost all of libvarnish as libvarnishapi. So your suggestion will, in a slightly different manner, become a reality eventually. |
Bugwash: Identify parts of libvarnish needed now |
Edit: Only VSHA is missing, a previous version of this comment was generated with wrong linker flags. |
bugwash: @dridi volunteered to write up a plan |
Expected Behavior
Build the slash-vmod mentioned in your news should work using varnish-devel package (on Rocky 9).
Current Behavior
varnish-devel is missing libvarnish.la. That is created during compilation but not added to varnish-devel during packaging.
Possible Solution
For now it's possible to build the slash-vmod by hand-compiling the whole varnish. But the docs for building the module on Debian suggest that installing varnish-devel (along with other build-tools) should be sufficient. However the rpm (package used here on Rocky 9) does not contain libvarnish.la.
Steps to Reproduce (for bugs)
Context
Trying to build slash-vmod.
Varnish Cache version
varnishd (varnish-7.3.0 revision 84d7912)
Operating system
Rocky Linux 9
Source of binary packages used (if any)
https://packagecloud.io/varnishcache/varnish73/el/9/$basearch
The text was updated successfully, but these errors were encountered: