Arch Linux User Repository

Well, thanks for all the suggestions-- this package is definitely better for your contributions :). I use cura all the time so I'll definitely be keeping this package in as good a shape as I'm able to.

It's funny, I've been using linux since the late 90s and never found a use for hard links until now, but this situation is perfect for them. Packaged files typically shouldn't be edited and packaged libraries basically never are, but if someone did need to edit one I'm sure the reason would apply to the other. I suspect you're right about the duplicate issue (and I'll check each release to see if they make a difference to the package size).

I'm not familiar with reflinks at all, but the caveats you listed are pretty big, especially the filesystem and utility ones for a package that's expected to work for everyone. Thanks for highlighting them though! You got me curious about how they work compared to symlinks and hardlinks and I'm going take a look :)

No credit needed. Glad that you're actively maintaining the package. In principle, using reflinks instead of hardlinks would be better in case some of the duplicates need to be modified independently from the others, but hardlinks is the most practical for now because...

• AppImages are based on a read-only file system, so there should never be any need for the duplicates to diverge.

• tar doesn't support reflinks, so the package would be larger and a script would have to be run after install to deduplicate the files.

• Only a few file systems currently support reflinks.

• Utilities to manage reflinks are still non-existent/rare.

• The duplicate files may be an upstream mistake that may be resolved in future releases.

@xiota: That AppRun script was a great find, your solution for replacing the scripts was a great idea, and your hardlink trick to reduce the size of the package by a couple hundred megs is amazing. Thanks so much for sharing all your ideas! I implemented them basically as suggested with a few minor tweaks and credited you in the commit history :)

Version 5.2.1 has ~290MiB of duplicate files that previous versions didn't. Fortunately, tar supports hardlinks. So some space can be saved by adding to prepare():

hardlink --content --maximize "$srcdir"

A dependency on util-linux may be needed for hardlink. On my computer with an NVMe drive, hardlink takes about 4-5s to run. The operation should still be fast on computers with HDDs because the files were recently extracted and should still be in cache.

The AppImage AppRun sets some environment variables to work around bugs. Instead of writing new scripts, if you patch the provided AppRun, upstream changes can be applied automatically.

[patch details removed because they've been added to the package]

@tornado99: Good catch-- looks like not running it from inside an AppImage broke file selection on KDE (and probably other non-gtk-based desktops). I just pushed a tweak to the launcher script that fixed it for me on KDE/Wayland. Let me know if you're still running into issues!

File Open doesn't seem to work now. Running on KDE/Wayland. Any solutions?

@magicalplace: I've added the symlink-- if it doesn't work for you I can probably just duplicate the launcher script since it's only a few characters of text :)

Please wait a few days before flagging this package as out-of-date. It is updated automatically on a daily basis.

@magicalplace: Hey, the reason for the binary name is because that's both what the included .desktop uses, and is the name of the actual binary. Would a symlink from /usr/bin/Ultimaker-Cura to /usr/bin/cura work with dmenu? I agree that something more generally cli-friendly would be nice.