On 6/2/24 22:15, Roman Haefeli wrote:
Hi
Following up the discussion about making Pd64 ready for prime time, I wonder if there is or - if not - if we can make up a few best practices rules regarding the packaging of Pd64 compatible externals.
What I gathered so far:
Package both floatsizes together. This allows to switch between Pd and Pd64 without having to re-install a package.
Use the traditional suffix for floatsize=32, eg. ".l_amd64" so that older (floatsize=32) Pd versions still find their externals.
Use new-style suffix for floatsize=64, e.g ".linux-amd64-64.so", that Pd64 tries it first, before it tries the "wrong" one with the traditional suffix.
no. Pd64 never tries the traditional suffixes. e.g. ``` $ pd64 -verbose -stderr -lib foo verbose(4): tried /usr/lib/pd/extra/foo.linux-amd64-64.so and failed verbose(4): tried /usr/lib/pd/extra/foo.linux-amd64-0.so and failed verbose(4): tried /usr/lib/pd/extra/foo/foo.linux-amd64-64.so and failed verbose(4): tried /usr/lib/pd/extra/foo/foo.linux-amd64-0.so and failed verbose(4): tried /usr/lib/pd/extra/foo.pd and failed verbose(4): tried /usr/lib/pd/extra/foo.pat and failed verbose(4): tried /usr/lib/pd/extra/foo/foo.pd and failed ```
so while the explanation is wrong, the conclusion is correct (use newstyle suffixes for Pd64 and oldstyle suffixes for Pd32)
- Don't pack too many archs and floatsize flavors in one package
since the resulting filename might hit filename length limit of some filesystem (namely ecryptfs on Linux, but probably others as well) > Do those rules make sense? Are there any missing?
i think this pretty much covers it all.
the filename problem is not limited to ecryptfs (actually, it shouldn't be a problem with ecryptfs, at least for consumers: when deken downloads a package, it excludes the architectures in the local file; however, the files must be storable on the machines that create the deken package (hopefully using a less limited filesystem and on the servers)
e.g. before i started providing Pd64 externals, i had all archs in a single deken package. all archs being: - Linux-amd64 - Linux-i386 - Linux-armv7 - Linux-arm64 - Darwin-amd64 - Darwin-arm64 - Windows-amd64 - Windows-i386 iirc, i kept the "Sources" package separate.
since i ship Pd64 externals I had to change this (in order to not violate rule #1): the architecture-specifying part of the filename would take 264 chars - that's without any library name or version.
according to https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits most filesystems (except those from the dark ages that would only accept some variant of 8.3 filenames) have a limit of 255 characters :-/
so I switched to shipping packages per OS (e.g. all Linux architectures for both Pd32 and Pd64 go into one package).
the assumption is, that people who like to switch between floatsizes (Pd32/Pd64) and CPU architectures without wanting to re-install the package, will typically use the same OS (that is: few people have the same filesystem mounted under at least two of Linux, macOS & Windows)
gmdsa IOhannes