File formats for mods?

[janbrohl]

The spec does not seem to state explicitly which archive formats are supported. In some places it is talked abut zip - please change.

• Even for zips it should be stated explicitly which compression modes are supported (bzip2? lzma?) or which version of zips in general https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
• As there are several ways to produce non-portable archives it should be stated somewhere what restrictions must be thought of when packing - like those on https://www.gnu.org/software/tar/manual/tar.html#SEC140 (of which most apply to zips, too).
  • If a file does not match these restrictions - users and authors should be warned about that.
• If not yet done so please add tar-support (same issues with compression modes and even mutually incompatible formats)
  • Tar files offer superior compression compared to zip files in some cases and according to #1344 at least .tar.gz can already be read by the client so this would possibly just be a minor change.
  • These could be used for gihub snapshot downloads directly like it is for https://github.com/KSP-CKAN/CKAN-meta

[techman83]

In theory anything SharpZipLib supports, we can support with little or no changes. I've not tested, but I think we already support tar.gz as the Metadata is downloaded as tar.gz for efficiency reasons. @dbent likely has more complete knowledge here.

[dbent]

Specs are nice and all but we have zero control over what mod authors publish. So let's say we decide to specify the exact archive format, what do we do if we encounter an archive that doesn't meet the spec? I see three options:

1. We pull an XHTML and refuse to process the archive: This would be pretty ridiculous since it would piss off users and mod authors who wouldn't see any reason for CKAN to refuse to process an archive any archive manager they download from the internet could handle.
2. We process the archive anyway but display a warning that it's not in the "correct format": What benefit would this have? Would users take different action based upon the warning? Nope. Would mod authors take different action based upon the warning? Nope. Would we take different action based upon the warning? Nope. Warnings without purpose just devolve into visual noise.
3. We just process the archive. If it works, it works. If it doesn't, it doesn't.

Option 3 certainly seems the most reasonable to me and since it doesn't use any format specification at all there's no point in formalizing such a specification.

As for tar-support, like @techman83 said, we already use it to download the repository archive. As a format for mods I don't see the point. The vast, vast, vast majority of KSP mods are distributed as ZIP archives, with the occasional RAR file here and there, and I've never seen a mod distributed in a TAR.

[janbrohl]

Just thought that having more precise error reports and having users more exactly know who to blame would help with support.

[dbent]

Just thought that having more precise error reports and having users more exactly know who to blame would help with support.

Fair and thank you for the consideration, but the goal should be that if a user can install a mod manually by using a archive manager of their choice, they should be able to install it with CKAN.

If they can't, we should fix CKAN, not have the mod author conform to a specification. There are already areas in the code which "normalize" some non-standard behavior in ZIP files.

And if they can't install it manually then it's obvious the mod author needs to fix their archive.

[netkan-bot]

Hey there! I'm a fun-loving automated bot who's responsible for making sure old support tickets get closed out. As we haven't seen any activity on this ticket for a while, we're hoping the problem has been resolved and I'm closing out the ticket automatically. If I'm doing this in error, please add a comment to this ticket to let us know, and we'll re-open it!