[aur-general] Support for source mirror lists in PKGBUILD

[Rashif Ray Rahman]

On 2 November 2013 00:14, Ido Rosen <ido at kernel.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