[MacPorts] #15395: Use primary port category for fetched distfile layout
wsiegrist at apple.com
Thu May 22 13:50:21 PDT 2008
On May 22, 2008, at 1:18 PM, Anders F Björklund wrote:
> William Siegrist wrote:
>>>> Why would people be browsing the mirrored files? Wouldn't the
>>>> interaction with the site mostly just be 'port' downloading a
>>>> mirrored file?
>>> And couldn't you make something like MPWA to browse the files,
>>> instead of having to wade through all the lowlevel yourself ?
>>> Or, for a low-tech solution, setup some symlink directories.
>>> "category/foo -> ../foo", then you can browse category/foo/ ?
>> I definitely hope that MPWA, `port fetch`, and ports.php will make
>> it so that users dont need to browse via Apache indexes, or even
>> know what distfiles.macports.org is. However, right now, I am
>> implementing the low level stuff. If I can also make it useful
>> while we wait on MPWA, then I think it can help some people.
>> Now, putting aside whether or not people should be browsing apache
>> indexes... I want the layout to use a category directory to make it
>> more manageable on the server for me. I could, and still might,
>> just make it work like I want on the server and leave MP base
>> alone. But I wanted to leverage some of the MP base functionality
>> since some work is already done there for me. It also seemed like
>> a chance to sync the layout convention used by Portfiles and
>> distfiles so they are the same.
> I guess I was just surprised to see another layer of directories
> proposed, after the earlier question on the list why it needed any
> directories at all and not just have all distfiles in one big
> directory... (like BSD)
The 1 big directory idea is fine if you're not the one who has to
manage it. The Fink mirror we provide does this with MD5-named
symlinks and its a pain anytime I have to deal with it.
> But as long as there is a migration path and someone willing to do
> the work, then I suppose it's worth the while after all. Kinda like
> the dp2mp transition, it seems like the innocent change could break
> some things.
Like I commented in the ticket, if it turns out to be a lot of work
and risk just for this 1 service, I'll just organize stuff manually on
the server and leave the base functionality alone.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080522/627821ff/attachment.p7s
More information about the macports-dev