Closed akien-mga closed 9 years ago
Thanks for raising this; the physfs used here unfortunately contains a small hack that allows ..
in the path (which was removed for portability across all the archive/platform types). I'll see if I can replace that and do things differently in the next version.
It's true that it is often easier to patch a few lines in a library so that it does what you need it to. I'd be glad if you can find a way to do this in your code and use the untouched physfs library.
I'm testing security updates for Mageia, and if a security vulnerability was found in e.g. physfs, we would have to patch not only the "pristine" physfs package that we provide but also every other software which bundles it as a static library (physfs is not the perfect example for such an issue, but we had a case recently with ffmpeg being bundled in quite a few image and video-processing software, it was a pain to patch and to provide official updates for Mageia 3 + Mageia 4 on two arches each).
Just giving some input about the "best practice guidelines" from my experience, of course you should find the good trade-off for yourself :-)
Implemented; if using the system library the distribution is a few hundred kb smaller :+1:
Many thanks :-)
Do you think I can backport those commits to 0.5.6 to package it for Mageia, or is there an upcoming 0.5.7 release?
I'm planning to make a new release soon so that will be easiest
Great, looking forward to it!
:+1:
When trying to update Mageia's cdogs-sdl package to version 0.5.6, I noticed that it build physfs as a static library and installs.
There should be a test condition in the CMakeLists.txt to verify whether physfs is already available on the buildsystem as a shared library, and if so disable the building of the static library.
As a rule Linux packagers avoid static libraries like pest; relying on shared libraries is one of Linux's advantages compared to bundled static DLLs with tons of security flaws on Windows :-)