On Nov 13, 2017, at 01:27, Mojca Miklavec wrote:
> A few things that could be of help here:
> - if github portgroup would support fetching from more than one repository
This has been in the back of my mind for awhile. Maybe the situation has come
up often enough by now that it's worth implementing.
Some kind of new procedure github.add_distfile. I can see this requiring major
restructuring of the portgroup though.
> - if we could store tarballs for different files to multiple distfile
> directories
That would be helpful in some situations, for example all the ports that need
to download a copy of the tcl source code. The assumption that all files are in
the same dist_subdir is probably burried pretty deep in the base code, though.
Individual ports or portgroups could probably do it by adding post-fetch and
post-extract blocks and reimplementing the fetch and extract code there but
that's messy.
If we were to extend MacPorts to base to offer this, I'm not sure what
interface we should expose to ports. Do you have any suggestions? One
possibility could be changing how the dist_subdir variable works. Currently
it's a single path value. What if we make it a list like the master_sites
variable, and each item in the list can have a ":tag" at the end to match it up
with distfiles. So then, taking the port tix as an example, you could do:
set tkv 8.6.1
master_sites sourceforge:project/tix/tix/${version}:tix \
sourceforge:project/tcl/Tcl/${tkv}:tcl
dist_subdir tix:tix \
tcltk:tcl
distname Tix${version}-src
distfiles ${distname}.tar.gz:tix \
tk${tkv}-src.tar.gz:tcl \
tcl${tkv}-src.tar.gz:tcl
Of course if we introduced this in MacPorts 2.5 any ports that used this would
be incompatible with earlier MacPorts. (They would get "POSIX ENOENT {no such
file or directory}")
> - rename the distfile on the fly (for example easily change v0.9.0.zip into
> sift-0.9.9)
That's easy to do for tarball-style URLs, which the github portgroup uses by
default, since the filename part of the URL is ignored by the server so we can
put any name there that we want.
For archive-style URLs, which sift currently uses, I imagine the "?dummy=" hack
in master_sites could be used.
