Jordan K. Hubbard wrote: >> 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.
Maybe not yet, but maybe they will come in later? Why not be collisions aware? > 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). Why are you against adding more logic to the 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... :-) And have one big cluttered directory without any links which file belongs to which port? With the distname approach, it adapts the layout of /opt/local/var/macports/distfiles where distfiles are currently stored locally. > 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. But maybe I want to see what files are on a mirror for some specific port without having to look through a list of all distfiles ever referenced by any port. >> 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. Please explain why? It would give us the possibility to prefer some mirror lists (e.g. sourceforge) which already got a world wide location aware mirror network. It would not be good to throw that away and use the one single mirror (in case even overseas) instead. Rainer _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
