On 4/10/24 07:12, Gleb Popov wrote:
On Wed, Apr 10, 2024 at 5:09 PM Brad D <soc...@brandongrows.me> wrote:
Is it uncalled for replacing problematic embedded libraries with equivalent
ones in a port as a dependency if the library is in the repo and well
maintained?
It is the other way around, we're usually striving to use
system-provided dependencies as much as possible.
Correct. If the library has not been customized within that port then
using a copy of the library from the ports tree has the benefits of
building it once when multiple things depend on it and updates +
vulnerabilities impact just that library can be tracked and applied to
just that library accordingly. If FreeBSD requires modifications to the
library for compatibility then that work is being done in one common
place with all dependent ports benefiting from the work.
If this port is the only user of that library then it may seem like
it doesn't make sense to extract it into a port that then has to be
maintained, but once again if there is a second consumer of the library
then there are benefits and it is harder to tell that is the case when
things are bundled.
If this port is using a modified copy of the library bundled in then
it may not be straightforward or be possible to use a copy from the
ports tree. If it does not build properly on FreeBSD then it may need to
be altered; if there is an unmodified port of the library then that port
may be useful to learn what changes to consider but they may no longer
apply. Watching for security issues of that library requires watching if
that modified copy is influenced by them for both how it is changed and
how it is (or could be) used;
Many projects I have looked at bundle libraries to make it easier to
build their port: smaller dependency list to give out, they depend on an
older/newer library than is found on their commonly supported Linux
distributions, or the library is not available as a package in a
commonly used repo. Some projects stay on top of security issues while
others may be oblivious to them for various reasons.
If your port is pretty straightforward, bonus points for using
EXTRACT_AFTER_ARGS+="--exclude path_to_a_folder_or_file_to_ignore" lines
being added to exclude extracting the shared/unneeded files. Any file
not needed to build the port and not included in a package of the port
is a file that took disk I/O and "maybe" CPU time to extract and on
cleanup to delete; builds to filesystems in RAM need less RAM to do so,
SSD users save on unnecessary write cycles of their drive, and less
things being written/deleted can mean less data to consider for its
related fragmentation.
I do not yet have a good workflow for determining what is not needed
short of trial and error. I presume a filesystem, where atime is
present/enabled, could identify all files read after extraction/patching
completed to determine it.
I've been meaning to do some basic testing of how many things could be
avoided/skipped at least from extraction by extracting all ports and
looking through duplicates and the folder I more commonly see now on
github projects of 3rdparty. This feels like the thing that Mark Millard
probably did somewhere and in a better way.
A port I had done some work on using a .tar.gz takes 10.3s to extract
and about 35-38s to clean all files. If reducing the extracted content
it takes 11.4s to extract and about 39s to clean (both timed on magnetic
hard drive with multiple runs ignoring the first on non-idle system).
Not all archives, archivers and archive formats benefit from knowing
what can be skipped. Decreasing 756M across 69609 files to 671M across
69555 files still sounded useful to me. I should try to see if I can put
it in a loop or use longer lines but it was a little bit of clutter as
the following:
EXTRACT_AFTER_ARGS+= --exclude ${WRKSRC}/*.ods \
--exclude '*.pdf' \
--exclude '*.doc' \
--exclude '*.xls*' \
--exclude '*.xcf' \
--exclude '*.blend' \
--exclude '*.blend1' \
--exclude '*.yml' \
--exclude '*.vcproj'
In my case, I did not have anything dynamic to the port but
conditionally adding more EXTRACT_AFTER_ARGS arguments would likely help
some ports further when port options change.
I am sure porters can make a better interface we can do so we don't
need to put "--exclude=..." (archiver specific parameter format) in
front of each file/folder in every Makefile. Though it might be
interesting to have a files to ignore list as an external file, I don't
know if we like more files making up the ports tree vs a cleaner
Makefile so someone better than myself will be making such calls of
"best practices" but each has both advantages and disadvantages.
