On 2 November 2013 00:14, Ido Rosen firstname.lastname@example.org wrote:
If metalinks/some external file are the only way to do this, you would need a local source entry for the metalink / mirrors file AND a reference to each file to pull from that metalink/mirrors file in the source array: (1) This breaks something conceptually to me, since the PKGBUILD is no longer the self-contained descriptor of where to get everything and how to put it all together into the package, now you need this other file or that other file at download-time (rather than just at prepare()/build()/package() time). (2) It also is less KISS than just having multiple source array entries for a mirrored file, since the packager and the person reading the package now need to understand another file format to parse out where the file is coming from. (3) Since there are extra files you're carrying along and it's not clear that those files are only needed at prepare() or build() time, now they're needed at initial download time, and the ordering of the source array becomes important, since you need the metalink/mirrors local file before the metalink link itself...
For metalinks and such, yeah. But in my proposed scheme, the .mirrors file would contain only alternative links. The primary links would still be part of the source array. This is how I envision the structure:
<<EOF http://somewhere.com/foo.tar.gz http://someother.com/foo.tar.gz
http://nextsource.com/bar.tar.gz http://nextsource2.com/bar.tar.gz EOF
So empty lines separate sources. The order shall follow the order of the sources listed in the buildscript. The PKGBUILD would still contain the sources in the format we know. If this .mirrors file does not exist, the PKGBUILD is still valid and self-contained.
Of course, this is very rudimentary. All it proposes is to fall back to alternative download links sequentially. If you want things like parallel downloads from multiple mirrors, that'd require more work.
And I'm not sure the pacman/makepkg devs like hidden files. I personally use a .contrib file to move over contributor tags when there are too many. It doesn't become a distraction and it's there for those who want historical information.
-- GPG/PGP ID: C0711BF1