Package: support and extract jar files like zip files

[gungun974]

What this PR does ?

This PR make the zig fetch command but also the zig package system handle jar like zip

A tiny story on why I make this PR

In one of my personal project, I used zig to make a cross platform audio player engine where FFmpeg was linked to my zig executable as a shared library.

Since the zig build system and package manager are so powerful, I'm able to directly fetch from the Internet my prebuild binaries of FFmpeg in my zig build so I could link them and install them along my executable.

Everything was fine for IOS, MacOS and even windows since I could download zip and tar but for my Android build the library was shared with jar file since some others android project could directly find the include and lib directories.

However when I try to fetch my jar file to extract manually the include and lib directories from github I got this error :

error: unsupported Content-Disposition header value: 'attachment; filename=default-arm64-v8a.jar' for Content-Type=application/octet-stream

I understand jar file are more than zip file but I still think zig should be able to understand them like regular zip. (If I take a jar and use unzip on it it's just works)

Maybe I'm wrong and also this is the first time I contribute here but I didn't see anyone discuss about that and since it was simple to add the mime-type and the file extension recognition as zip

I still hope you will find this PR interesting ^^

[alexrp]

Seems like a reasonable use case to support, but I'll let @andrewrk weigh in too.

[mlugg]

FWIW, I don't find this particularly compelling, because there are many formats which are ZIP in disguise, but it seems pretty clear to me that, for instance, we shouldn't have special handling for the .docx extension. Why should we give .jar special treatment in this regard?

[alexrp]

Why should we give .jar special treatment in this regard?

I have to imagine FFmpeg is not the only case where you might find native libraries in a .jar. OTOH, why would anyone put native libraries in a .docx? 🤔

To be clear, I also don't think .jar should be the one outlier here; I would also argue for allowing .nupkg because distributing native libraries on NuGet is a fully supported use case, and you could very easily imagine someone wanting to link a library distributed that way when targeting *-windows-msvc.

[andrewrk]

Ultimately the package manager has to make some subjective decisions about what is a "common" archive format.

In order to future-proof we have #14294 but for now we just have to exercise taste, which I find to be pretty easy to do:

• .jar - ✔️
• .docx - 😆
• .nupkg - ✔️