On Nov 5, 2008, at 21:19, Bryan Blackburn wrote:
On Wed, Nov 05, 2008 at 08:29:46PM -0600, Ryan Schmidt said:
On Nov 5, 2008, at 16:55, nox wrote:
Le 5 nov. 08 à 23:26, Ryan Schmidt a écrit :
On Nov 5, 2008, at 02:27, [EMAIL PROTECTED] wrote:
+master_sites ${homepage}attachment/wiki/WikiStart/
+distfiles ${distname}${extract.suffix}?format=raw
Cool trick!
Hmm, except for the fact that that's the filename that ends up
on the
user's system, and on the mirror; see:
http://distfiles.macports.org/gtkimageview/
See attached patch for a better solution.
<gtkimageview.diff>
By the way, shouldn't it be better to create a new variable
`fetchfiles` which would
replace the default mechanism offered with master_sites distname
extract.suffix and all?
Tricky ports like this one would just have to write the url of the
file(s) to fetch in `fetchfiles`.
I'm not seeing how "fetchfiles" would work, in all the variations
that we
have to support (one or multiple distfiles, on one or multiple master
sites).
I'm comfortable with the workaround presented in my patch. It's
used by
several ports already. We could document it in the Guide and in
that way
make it an official recommendation for this situation (when
downloading
through a server-side script instead of just downloading from a
server
directory).
Doesn't your workaround also have issues with multiple distfiles
since you
use that variable in the URL?
master_sites ${homepage}attachment/wiki/WikiStart/${distfiles}?
format=raw&dummy=
How does that work with 2+ files?
It... totally doesn't. I guess I didn't think through my objection
very well. :)
Perhaps a different approach could be to use just a placeholder in
master_sites:
master_sites ${homepage}attachment/wiki/WikiStart/<file>?
format=raw&dummy=
or something to that effect (since <> are not valid in HTTP URLs).
When no
<file> is present, append to the end like we do now.
Placeholder sounds very good. I might prefer a sprintf placeholder,
like %s (% isn't valid by itself in a URL either).
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
