MacPorts caching of distfiles [was Re: ntfs-3g 1.1120 source missing]

[Jordan K. Hubbard]

On Feb 24, 2008, at 7:46 PM, Rainer Müller wrote:

> Jordan K. Hubbard wrote:
>> On Feb 23, 2008, at 8:05 AM, William Siegrist wrote:
>>> So whats left? I think you'll want a special hostname for these?  
>>> Maybe http://distfiles.macports.org/<group>/<port>/<file>?
>> I'm not sure what value <group> adds.  <port>/<file> would seem  
>> more than reasonable, and a completely flat namespace even more so  
>> since it then becomes very easy to add to the search path for all  
>> ports.
>
> All distfiles in one single directory? I am against that at all!

Why?  Collisions?   If so, please name the collisions in question,  
because I cannot find any.

If you add indirection to this then you lose the ability to have a  
global URL path that points to a mirror (either that or you need to  
add extra logic to the MacPorts fetch code).

> <group> would be category, I think. But some ports also use the same  
> distfiles by specifying distname (e.g. vim and vim-app). So maybe it  
> would be better to use the distname of the regarding port to avoid  
> mirroring files multiple times.

Or you could just use a flat namespace... :-)

> Although that takes away the category information. I even do not  
> like the fact that /opt/local/var/macports/distfiles is not  
> categorized. But the whole categories handling in MacPorts is a bit  
> broken; that's another topic...

I fail to understand this stubborn insistence on date stamp and group  
information for files which are simply not meant to be user visible.   
There is no group information you need to see on the distfile mirror  
because you won't be managing the distfile mirror.

> And it would be no problem to prepend URL with an advanced scheme to  
> the master_sites list (or even add it at the end if the sourceforge  
> mirror group is present, as said earlier). I think it would be just  
> a bit more work to do it for ports using tagged mirrors also, but  
> surely not impossible.

This is over-engineering at its finest.

- Jordan