❦ 21 avril 2021 08:04 +02, Willy Tarreau:
> William suggested that I was needlessly seeking for trouble and that it
> was pointless to keep compatibility for *both* an external version and
> an internal one. While I initially wanted to demonstrate him he was wrong,
> I realized that I was the one wrong because the lib had considerably
> stabilized (no change over one year), and after all we already embed a
> few other things like xxhash and ebtree without offering the possibility
> to build with an external variant, and in the end it probably was the
> right solution.
>
> So after changing my mind, I would go with the following approach:
>
> - building with USE_SLZ=1 => always use the embedded one
> - building with USE_ZLIB=1 => always build using the user-provided zlib
>
> We'd enable USE_SLZ by default and it would be disabled when ZLIB is used
> (or when SLZ is forced off). This way we could have fast and memory-less
> compression available by default without the hassle of cloning an unknown
> repository.
>
> Does anyone have any opinion, objection or suggestion on this (especially
> those in CC who participated to the first discussion or who could have
> packaging concerns) ? Barring any comment I think I'm going to do this
> tomorrow so that we have it in -dev17, leaving a bit of time for distro
> packagers to test and adjust their build process if needed.
>From a distribution point of view, we don't like bundled dependencies.
However, as I see it, libslz is an internal lib (like ebtree), so I
don't think this is really a problem. Moreover, we don't have the
external lib in Debian, so there is no duplicate work. Is there any
practical advantage of keeping using zlib (for a user)?
--
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)
