You are not logged in.
Arch packages don’t have a distinctive MIME type on my system which would be necessary to register a default application to them (e.g. something like the GDebi installer is for .deb packages).
Why not? And what would an acceptable family of MIME types be? something like this?
application/x-arch-package+gzip, ...+x-xz, ...
Offline
Keep in mind that packages from official repos now use zst compression and are named as *.pkg.tar.zst files , pkg.tar.*z won't cover them.
MIME types seem to be used almost exclusively by graphical programs .
pacman is a pure CLI application, what would be gained by having a mime type for packages ?
Last edited by Lone_Wolf (2020-06-19 13:22:34)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Offline
https://specifications.freedesktop.org/ … ubclassing
I encourage you to create a mimeinfo subclass for compressed tarballs (every compression format recognized by libarchive is eligible) that matches on any tarball filename stem which ends in '.pkg'. This mimeinfo subclass would then be recognized as e.g. application/x-pacman-pkg+tar, and I guess a GUI for libalpm would be able to associate itself as a file opener for it.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Thank you for that reference! Hmm, there’s something inelegant about that subclassing system because new media types have to be created for combinations instead of having a way to chain them.
Therefore mimetypes like x-xz-compressed-tar exist and I’d need to create another subclass for each of those (as well as for plain application/x-tar):
$ grep compressed-tar /usr/share/mime/subclasses
application/x-compressed-tar application/gzip
application/x-lrzip-compressed-tar application/x-lrzip
application/x-lzma-compressed-tar application/x-lzma
application/x-webarchive application/x-compressed-tar
application/x-lzip-compressed-tar application/x-lzip
application/x-bzip-compressed-tar application/x-bzip
application/x-xz-compressed-tar application/x-xz
application/x-zstd-compressed-tar application/zstd
application/x-lz4-compressed-tar application/x-lz4
Right? Where can I look up which compressions are supported? Does libalpm e.g. also support .pkg.zip?
Last edited by flying sheep (2020-06-21 13:38:42)
Offline
Where can I look up which compressions are supported? Does libalpm e.g. also support .pkg.zip?
Anything supported by libarchive is supported by libalpm. So technically .pkg.zip files should work.
Offline
I’d need to create another subclass for each of those (as well as for plain application/x-tar):
Why? The repos only use zst compression. xz was formerly used, but no longer. The only way anything else would be used is for locally built packages and then only if you've explicitly specified a different compression algorithm in your makepkg.conf.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
flying sheep wrote:I’d need to create another subclass for each of those (as well as for plain application/x-tar):
Why? The repos only use zst compression. xz was formerly used, but no longer. The only way anything else would be used is for locally built packages and then only if you've explicitly specified a different compression algorithm in your makepkg.conf.
Sounds like you've answered your own question.
But also please note that the default compression for makepkg.conf and thus makepkg is still xz, not zst. zst is only the default in chroot builds, i.e. extra-x86_64-build or makechrootpkg.
There are also other tools like https://github.com/jordansissel/fpm/ which only support some cherry-picked list of compression types and haven't updated their pacman package generator in 4 years. Though I think based on what I've seen people attaching to github releases, this produces files named .pacman or something.
cmake also had a merge request to add pacman package generation, though it died once I submitted review comments, lol: https://gitlab.kitware.com/cmake/cmake/ … uests/4185
(But looking at it again, it defaulted to zstd.)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline