On 2020/08/04 18:07, Christian Weisgerber wrote:
> On 2020-07-30, Klemens Nanni <k...@openbsd.org> wrote:
> 
> > Any OKs for this diff which updates and brings in all the support?
> 
> I haven't gotten around to really looking at this... but since it's
> committed now:
> 
> This changed rsync from a self-contained port that you could quickly
> compile on a clean box to something with this list of dependencies
> on clang archs:

This is mostly for zstd. xxhash and lz4 are self-contained and small.
(zstd is also small but the additional build deps are slightly annoying
- though do people really not just pkg_add it? - as are the compiler
requirements on old-gcc archs).

> archivers/xz
> converters/libiconv
> devel/pcre
> archivers/lzip/lunzip
> devel/dwz

dwz is only for DEBUG_PACKAGES archs.

> devel/gettext,-runtime
> devel/gmake
> archivers/lz4
> sysutils/xxhash
> sysutils/ggrep
> archivers/zstd
> net/rsync

We use rsync to distribute the CVS repository, having some lightweight
compression on the majority of clients fetching this really seems
like a good thing. (lz4 would do though zstd is a lot better).

> On non-clang archs, you can forget about just building it.  Ports
> gcc is required:
> 
> devel/metaauto
> archivers/xz
> devel/help2man
> devel/autoconf/2.69
> devel/automake/1.16
> devel/autoconf/2.67
> devel/libtool,-ltdl
> devel/libtool
> devel/gmp,no_cxx,bootstrap
> devel/mpfr
> devel/libmpc
> converters/libiconv
> devel/gettext,-runtime
> devel/gettext,-textstyle
> devel/gettext,-tools
> archivers/lzip/lunzip
> devel/gmake
> archivers/lz4
> sysutils/xxhash
> devel/libsigsegv
> devel/m4
> devel/bison
> devel/libexecinfo
> lang/gcc/8,,-libs
> lang/gcc/8
> lang/gcc/8,,-main
> lang/gcc/8,-c++
> lang/gcc/8,-libs
> devel/pcre
> sysutils/ggrep
> archivers/zstd
> net/rsync
> 
> The iconv FLAVOR doesn't build:
> 
> Missing library for iconv>=0.0
> 
> Never mind that the iconv flavor doesn't make sense any longer,
> given that there are now multiple library dependencies and libiconv
> is a build dependency anyway.
> 
> -- 
> Christian "naddy" Weisgerber                          na...@mips.inka.de
> 

Reply via email to