On 1/8/20 7:02 PM, Ken Moffat via lfs-dev wrote:
On Wed, Jan 08, 2020 at 03:59:32PM -0600, Bruce Dubbs via lfs-dev wrote:
I've been seeing some references to zstd lately. AFAIK, the only use of it
right now in LFS/BLFS is for some tests, but I think it will become more
common in the future.
I downloaded the tarball from https://github.com/facebook/zstd/releases and
the build is pretty easy. Actually they support make, meson, and cmake.
I was able to build with
make
make prefix=/usr install
Build size 17 MB
Install size 3.1 MB
Time was about 0.5 SBU
We might want to make some changes to install in /bin and /lib instead of
/usr and to remove or suppress the static library, but I haven't looked at
that yet.
Should we add this now or wait a while until more packages start using it?
Using this lists suggests you are thinking of adding it to LFS
rather than to BLFS. What is the current justfication for that ?
The reason is consistency with gzip, bzip2, and xz. All of these are
compression/decompression utilities and should be treated in the same way.
I'm sure your mention of /bin and /lib implies some reason for
adding it, but from the little I know at the moment I've flagged
it under 'might be needed in BLFS one day'.
As above, I was treating zstd the same way as the existing
compression/decompression utilities.
I do agree that we could classify this as 'might be needed in {,B}LFS
one day', but I am anticipating what I think upstream will do. I just
don't know when. The issue really is whether we should be proactive or
reactive.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
