Metadata for download packages

[Holger]

Given that, can I ask / recommend that a write-up and set of pointers also be added to the main RnD Levels & Artwork page?

It's currently not that ideal, I know. I have answered some more in a private mail to you.

Actually on a related matter, I wonder if your own files with embedded version numbers, like Emerald_Mine_Club-3.2.0.7z, could also have version-less endpoint names (Emerald_Mine_Club.7z & Emerald_Mine_Club.zip, in the example case). That would make it easier for someone to script up 'download RnD and all associated level materials, at their up to the moment current editions', without needing to constantly update.

I do understand for what purposes this could be useful (and also thought about this before, for example, by simply setting and updating symbolic links to the latest versions). However, I'm not sure if the advantages would outweight the potential disadvantages of not knowing which version was effectively installed, or if new package versions are available to which the setup should be upgraded to. Then, it could also be possible that the list of available packages itself changes over time (with new packages being added to the list, for example), so I'm not sure if it is really possible to have a solution that works without some sort of curation from time to time.

Of course my request for a machine readable metadata for that would also cover that need. Then the script only needs to download the one master 'all recommended downloads metadata' file, then follow its instructions. (I imagine this would contain metadata like: url; human readable name; short description; author(s); copyright or license info; download size; unpacked size; sha256-or-similar integrity verificator... and I should dredge up that other thread and put this part there...)

Yes, this seems to be the better approach. (While having the "disadvantage" that the curation would have to be done by me. )

[filbo]

Yeah, I get the ambivalence about versioned vs versionless filenames...

While having the "disadvantage" that the curation would have to be done by me. ;-)

Seems like you are already doing such curation, for the maintenance of the human-readable Levels & Artwork page. Maybe you could add so much metadata to the metadata file, that you could crank out a new rev of Levels & Artwork by just running a converter script on the metadata? So then you're back to just maintaining it once... :)

[Holger]

Seriously, I think it's best if the curation is done by myself, of course (with regard to that partially outdated list of level packages as used by the Debian/Ubuntu post-install script you described in your related post (that I still want to comment, too)).

Creating the whole "Levels & Artwork" page from metadata, while having its charm, seems to be a bit too much for now, especially as different distributions might prefer different selections of level packages (maybe depending on size, legal status or suitability for certain interest groups, like children etc).

So, looking at Debian/Ubuntu again, a simple file like "levelsets-debian.csv", containing lines like

Code: Select all

"Emerald Mine Club", "3.2.0", "Emerald_Mine_Club-3.2.0.zip"

could do it (and would be usable for both initial installs and subsequent package updates, updating only the level packages (after updating the main program package) that really have changed since the last update).

This file "levelsets-debian.csv" could then itself be automatically created from a template after updating packages on my site.

[filbo]

The Debian install script I'm hoping to replace has embedded md5 checksums. Please include sums in your csv: any common hash would probably be acceptable, but the modern 'standard' for not extremely high security purposes seems to be sha256, so I recommend that.

It also includes one other metadatum in all records: an unpacking path (actually a 'subtraction path e.g. 'remove rocksndiamonds-4.4.0.5/ from the front' of paths extracted from that version's Linux source/binary/install tarball).

And on further inspection, the script does several other things which I could characterize as repairs or unsubmitted bugreports -- so, actually, I would like to request to put this discussion 'on hold' for now. I don't want you to spend time on something which would end up not solving the issue I'm trying to solve, and I can't fully articulate the issue yet! :)

I'll comment here with full details, eventually; please make no changes along these lines (on my behalf at least) until then.

[filbo]

Is it possible for you to chop off this discussion, from 3rd post (" It's currently not that ideal "), into a new separate post with subject line 'metadata for download packages' ?

[Holger]

Done.

[filbo]

Nicccce :)