Add AUR instructions to README.md

orhun commented 4 years ago

Hi, I'm an Arch Linux package maintainer. I'm submitting this PR to let you know that I created the following packages for the installation of termimage on Arch Linux and other distributions that support installing packages from AUR:

termimage (builds from source)
termimage-bin (latest binary)
termimage-git (VCS/development package)

I also updated README.md about installation from AUR. (26b5ab9)

BR, orhun.

nabijaczleweli commented 4 years ago

Rewritten and merged in 293528716094587b725ab739384f420dbb4fd517; thanks!

orhun commented 4 years ago

Hey again!

Do you mind adding Cargo.lock file to the project? It's important for using --locked flag while building which affects the reproducibility of the packages.

Also see: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

Thank you, orhun.

nabijaczleweli commented 4 years ago

My stance on this has not changed since 2016 – Cargo.lock is a build artifact and termimage is a library with a forward-facing binary example – I will not be checking it in.

For reproducibility, I don't think there's a any downside to including the lockfile you get from your build into the packaging metadata, is there?

anthraxx commented 3 years ago

This is not really how distro packaging toolchains work or should work, it wouldn't be the right place to do it. I understand that you personally don't like it, but it basically became a standard across most of the ecosystem to maintain a Cargo.lock inside the repository to support reproducible builds. It is a relatively low effort to maintain and creates also a uniform output across all different distros and systems that can use the same lock file. an alternative approach would be to just upload the Cargo.lock whenever you issue a github release as an additional release artifact if you just want to keep your repo "clean".

It would be amazing if you can reconsider this topic

nabijaczleweli commented 3 years ago

I've thought on and off about this since your post, and:

lockfiles reflect, by definition, the resolved package tree,
which will, by definition, be different across platforms, let alone feature gates, so
me uploading the lockfile off my x86_64-pc-windows-gnu desktop (or, indeed, AppVeyor, which is x86_64-pc-windows-gnu and/or x86_64-pc-windows-msvc; uploading one off Travis would require another build cell, which, considering how long the builds are anyway nowadays, is not gonna happen) is misleading at best for the packaging use-case, and
distributions might (do) ship Rust and crate versions different than upstream and crates.io, respectively,
which is solved by you putting the lockfile(s) generated in the right versioning universe (which, for simple distributions, might well be upstream and crates.io) for the right platforms with the right features inside the source package – they're probably gonna be the same across linux and kfreebsd for the most part, but on the hurd? how about ksolaris? I refuse to take the responsibility of finding out, so I will not fuck around.

nabijaczleweli commented 2 years ago

Released in v1.2.0.

nabijaczleweli / termimage

Add AUR instructions to README.md #16