[41513] trunk/dports/devel

[Bryan Blackburn]

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, devans at macports.org 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?  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.

Bryan