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

[Ido Rosen]

On Fri, Nov 1, 2013 at 3:27 PM, <alexander.r at gmx.com> wrote:

> On Fri, Nov 01, 2013 at 12:14:25PM -0400, Ido Rosen 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
>
> This is obviously incorrect. Please re-read your message, so that no one
> has to
> waste more breath.
>

I've submitted a patch for the mirror idea that follows Jerome's way of
doing it, which Florian modified and sent over to pacman-dev.  If you want
it done differently, submit a patch to help make pacman better rather than
making toxic comments, you'll alienate less peers that way.  :-)

The point that perhaps I wasn't making clearly (or verbosely) enough was
that in the current implementation of makepkg, adding the metalink/.mirrors
file to the source array then downloading it in prepare() as you yourself
suggested does involve having those files as local files (download_local()
in makepkg.sh.in) in the PKGBUILD and then referring to them again in the
PKGBUILD, on top of having to understand the metalink format or a new
.mirrors format (as opposed to a simple additional array entry as was
Jerome's suggestion).  The result is that the reader must understand those
extra file formats and must go somewhere outside of the PKGBUILD to
understand where downloaded files are coming from.  This would be the case
if metalinks/a separate file were the only or primary mechanism for
supporting mirroring.  For the common case I brought up, where there are 2
or 3 mirrors for the primary source file(s), metalinks/a new .mirrors file
format seems overly complex to me.


> > 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.
>
> > I'm not opposed to adding metalink, torrent, carrier pigeon, and
> sneakernet
> > support to DLAGENTS by default
>
> You are the one, who wants metalink, torrent, carrier pigeon, and
> sneakernet
> support to be implemented in pure Bash as part of makepkg. With numerous
> mirrors and
>

Nice straw man.  You were the one who suggested metalinks; I said I don't
care either way if they're implemented or not (i.e. it is not a vote for or
against their implementation...  What I said in the paragraphs you
misquoted is that I'm neutral to whether the extra DLAGENTs like metalinks,
torrents, etc. are implemented or not, and that this is a separate issue.
 Jerome's proposal is a simpler and more KISS way of solving the common use
case / problem that I was trying to solve: mirror A is down for a file may
be downloaded from mirrors A or B.


> sofisticated source arrays, cluttering PKGBUILD source, nobody would
> indeed be able
> to understand, what's going on in it's prepare() or build() functions.
> Obviously,
> fell free to do something like that yourself; all you need is to re-define
> prepare()
> to do whatever you want. Just don't advertise that as something, great
> enough to
> become the standard.


I did like Jerome's suggestion, which was different and simpler than my
original suggestion of supporting sources as an associative array.  That's
why I implemented it and sent it to Florian.  The only change that patch
makes is that now makepkg aborts at the end of trying to download all the
files rather than after the first failed download, and treats source
entries with duplicate filenames as equivalents/interchangeable/mirrors.
 To put it more simply:

source=("http://a.com/file.tar.gz" "http://b.com/file.tar.gz")
^ now makepkg recognizes these as mirrors of file.tar.gz, and will only
abort if *both* (rather than either) fail to download file.tar.gz.

Cheers,
Ido


> --
> My AUR packages -
> https://aur.archlinux.org/packages.php?SeB=m&K=AlexanderR
>