If this tarball constantly changes, it's not really an option. We need to be able to rebuild the same package on rebuilds.

so you're telling me, doug, that it's more acceptable to have a collection of RFCs that are 8 months (or more) out of date than a package that would not be able to be rebuilt.

(ignoring, of course, that the package hasn't even included the newer batched tarballs as well)

EDIT:
scratch that, updated yesterday to include newer releases

EDIT2:
however, it ALSO includes https://www.rfc-editor.org/rfc/tar/RFCs8001-latest.tar.gz, which DOES change. so is your argument valid, doug, or is the maintainer incorrect in adding that source?

live version:
[bts@cylon ~]$ curl -sL https://www.rfc-editor.org/rfc/tar/RFCs8001-latest.tar.gz | sha256sum
b4aac946dba8c73a03ac88958249252625d71ced5026fde577706b8d3e28d16d -


pkgbuild has 9fcc3c9fec46a8286ee72f0f521d092aa171cc61b840f025691ea4d8ae7c9634 showing that yes, it regularly changes, yet is included in the PKGBUILD. if this is included, why not just use the -All tarball instead?

You're right, that's not really usable, either

Sergej-

Might I offer a possible solution?

Instead of packaging the tarballs themselves, instead package a cronjob and simple script that simply fetches https://www.rfc-editor.org/in-notes/tar/RFC-all.tar.gz and unpacks it to /usr/share/doc/rfc/txt (pdf versions also available) according to the packaged cronjob. That way the package will have very little changes from its sources (only a cronjob and a script), and the RFCs will be kept updated regularly. Unfortunately, it ALSO depends on a reliable network connection on the client it's installed on- so that's a downfall.

(alternatively, there is this: https://trac.tools.ietf.org/tools/ietf-cli/ )

I'm not sure of a clean way to do this if Doug's objection is, in actuality, a requirement of packages.

Nope, replacing package content with a cronjob that pulls them is not a solution at all, however if that's what you wish to do, do it yourself.


either way, yes it is bad if sources are non-deterministic and change, this would kill reproducible builds afford and even without that should sources be deterministic per se.
One variation would be to store the latest non-deterministic tarball with a timestamp/date on our archlinux archive, use a according pkgver and pull non-deterministic sources from our infra instead.
This could be updated here and there if required and still be a proper and deterministic package with actual content.

I wasn't even aware hosting something on Arch infra was even a possibility! Yes, by far that'd probably be the best way to accomplish things.