request: PKGBUILD

[afontenot]

Hey, thanks for your work on improving rtorrent. I'm also enjoying your nodejs-flood AUR package, and it would be great to see a PKGBUILD for your rtorrent fork in the AUR as well.

You might run into an issue where a moderator doesn't think your changes to rtorrent are substantive enough to merit an AUR package for it and deletes it. I've run into this before. In this case, if you could have the CI upload an up-to-date PKGBUILD to the releases, that would make it easier for Arch users to keep up to date with this package.

If you feel like it, it might be nice to have a CHANGES document listing the most significant changes you've made to vanilla rtorrent. I've been appreciating the access to sequential download from Flood, but it would be nice to know what else is different without having to trawl through commits. (A list of changes would also help justify an AUR package at some point, I suspect.)

[jesec]

Since this is a feature request, I am moving it to discussions.

This is a good idea.

However, note that PKGBUILD is NOT a package. It is a "recipe" that instructs a set of scripts and build tools to compile a package from sources.

Unlike Flood, it is drastically more complicated to handle dependencies and build tools for a C++ program like rTorrent/libTorrent. While the procedures are quite established, it would take significant efforts to get all those things sorted out.

Alternatively, it might be an option to publish a -bin package, which simply downloads prebuilt deliverables. This is not encouraged by AUR guidelines, though.

I will certainly take a look when I have time.

[afontenot]

Sorry, I wasn't familiar with Github's discussion feature, I don't think I've seen it before.

I don't think it would be too bad because there's already a PKGBUILD for vanilla rtorrent you could use as a base. You'd probably just need to point it at your repository, and include a unit file for systemd or anything else your version needs. I'd be happy to help with this but I assume you want it automated with your CI anyway.

For me having a PKGBUILD means I don't have to trust an additional binary source, so I can just audit commits to this repository as they come in while still having the convenience of the package being installed system wide. Probably not a big consideration for most people but it's something I think about. Anyway, thanks for considering this idea.

[jesec]

There are significant differences in build tools. This repository uses more modern build tools like CMake or Bazel, which is very different from the original configure + make schemes. Additionally, C++ 17 support (a modern toolchain) is required. It is likely that I would have to write a PKGBUILD from scratch.

I also agree that the build process should be auditable and reproducible. That's why I never upload binaries. All build and release procedures are handled by continuous integration scripts. You can easily check build logs in Github Actions. Outside dependencies of published builds are handled by Bazel which uses predefined SHA256 hashes to ensure reproducible builds.

[afontenot]

Didn't realize you'd already upgraded the build system. I'll poke around with writing a working PKGBUILD that works in a minimal Arch container and post it here if I have any luck.

One limitation of the current build approach is that there aren't packages for distributions other than Debian. So on other distros you'd just have to chuck the binary somewhere in your home directory or in /usr/local, which isn't really how I like to manage things. I do appreciate you not uploading binaries, although AFAIK there's no way to verify the files on deb.jesec.io without comparing a checksum with the CI versions of the files. Maybe I'll just switch my containers to Debian and use the CI builds for convenience.

[afontenot]

Here are working PKGBUILDs for your rtorrent and libtorrent forks.

libtorrent-PKGBUILD.txt
rtorrent-PKGBUILD.txt

Note: it doesn't look like you have any releases out the door for your libtorrent fork, so I had to depend on a -git version. As soon as you have something there it would make sense to switch it to a normal release so the rtorrent PKGBUILD can depend on a specific libtorrent version.