Upstream (github nick rfc1036) is a Debian developper. We do refer to the github project page as upstream URL but we use the Debian mirror to fetch the source tarball. I don't really see a problem here. Cheers.

the current source is not an https one, and the debian people get it from github too.

@vesath, I cannot think of a single good reason to explicitly use the debian mirror either.

More worryingly, the debian mirror is garbage and if we wanted to use temporary, time-limited mirrors, we should use our own where at least we're the ones who choose when it gets silently removed:  FS#59298 

I must confess myself entirely bewildered, why anyone would want to use some mirror if it could be avoided, since conceptually it is kind of indirect even in the best case where upstream is also the debian maintainer -- security-wise it might not matter, but it seems bound to cause pointless confusion.

Boy, the drama. You should be just as bewildered why someone would want to use a private, for-profit corporation as a service to obtain tarballs which:
- they do not even host but generate on-demand; we've seen the hash of given tarballs change whenever they fell out of github's caches and had to be regenerated, though admittedly not in a while.
- names said tarballs only after their version, not the project name, which is ugly and causes collisions for sourceballs.

Again, there's no debian folks mirroring stuff, there's the upstream dev uploading release tarballs directly to a debian server. Please explain in concrete terms (no handwaving) why using it is a problem and how you have the time to care about insignificant details like this.

fakeroot is also developed by debian, and its upstream is salsa.debian.org, but they only upload tarballs to the debian pool and don't even tag releases. They're not "releasing tarblls directly to a debian server", they're creating a debian package using their own original sources and using the standard debian packaging workflow to *mirror* the sources to the designated debian server for mirroring sources.

And, guess what? Debian stopped shipping a given version in their repositories, so the source went missing.

I don't understand why you think I care whether it comes from a private, for-profit corporation. I care about reliability, and debian apparently isn't, whereas I've personally never once seen tarball hashes change without force-pushing tags, plus git-archive(1) is supposed to be deterministic.

As for naming tarballs after the version... dude. Do what everyone else does for like 90% of all packages anywhere ever. man PKGBUILD ==>

"
It is also possible to change the name of the downloaded file, which is helpful with weird URLs and for handling multiple source files
with the same name. The syntax is: source=('filename::url').
"

Github doesn't name anything after the version, makepkg just doesn't use --remote-name --remote-header-name to follow redirects or Content-Disposition headers in unpredictable ways, and relies on you setting that via makepkg's designated syntax.

I'm not your "dude" and you can "fix" this important issue when you gain access to [extra]. Goodbye.

I should also note that upstream's own GitHub README file contains

"The canonical distribution point for releases of the program is
http://ftp.debian.org/debian/pool/main/w/whois/ ."

While that is the case, this is where I will get the tarball to build our whois package.