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.