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

On 6/2/24 22:15, Roman Haefeli wrote:

Then I wonder how to go about existing Deken packages. In order to add Pd64 support, I would like to upload an upstream version that has been already uploaded. If I add only the floatsize=64 flavor as a new package, I violate the first rule. It is ok to upload the same version again, but with both floatsizes? Should the old packages be deleted or will it be automatically overwritten? Or is it mandatory to bump the version?

deken is anarchic (although it still only supports a single server).

- nothing is deleted automatically - every package is stored in a namespace that belongs to somebody (e.g. http://puredata.info/Members/zmoelnig or http://puredata.info/Members/rdz) as such, uploading a new package to *your* namespace, does not change anything within *my* namespace - in general, you should not remove (your) old packages - you never should remove old packages by others (though, generally, you will not have the permissions to do so)

- there is no (technical) rule prohibiting the upload of an already existing version of the external. - a version bump will sort the package before the original version. - a version bump might collide with a future upload of the original package.

personally, i think there are a couple of best-practice ways to deal with your problem

# same version if the package is bit-for-bit identical with the original package (modulo the new files), then i think it would be OK to re-upload under the same version. this should be read as: if you have the sources of the original package and build them into Pd32 externals (possibly tweaking your build environment) and the result is bit-for-bit identical with the original upload, then you can use the same (tweaked) environment to build Pd64 externals and include them in a re-upload a much relaxed interpretation could read: just take the original package files and add the Pd64 externals; then re-upload while i think that the 2nd interpretation is OK in most cases, we should always strive for the 1st one

# changed version the version does not need to be *bumped*. you could add a "vendor suffix" (e.g. "-rdz1") to distinguish it from the original upload, with a minimal risk of getting into a version clash with the next "official" upload.

you could even *lower* the version. e.g. adding a suffix "~rdz1" or just "~" will sort the newly uploaded version (just) below the official version. i think the net result would be, that people on Pd32 will get the original package (without Pd64 externals). After switching to Pd64, the externals are gone and they need to re-install them. this time, they will (only) find your (Pd64-capable) version and install that (overwriting the original one). switching back to Pd32, things will continue to work.

with a changed version, you could re-build the Pd32 externals without worrying too much about bit-for-bit identical results, and without stepping on the toes of the the original uploader. lowering the version, instead of bumping it, is an additional courtesy to the "owner" of an external.

gmsard IOhannes

PS: in the past we have seen uploads for new architectures (e.g. Darwin-arm64) that did not worry too much about all this.