#19338: macports versions > 1.6, error with http repositories --------------------------------------+------------------------------------- Reporter: mirko.bordignon@… | Owner: jmr@… Type: defect | Status: assigned Priority: Normal | Milestone: MacPorts 1.8.0 Component: base | Version: 1.7.1 Keywords: | Port: --------------------------------------+------------------------------------- Comment(by raimue@…): The patch has a flaw, it still has to be `[file normalize [file join [getportdir $url] .. ..]]`. Otherwise it would try to open files in `.../category/portname/_resources/...`. Note that the given URL is meant to be a porturl, not a source. We don't know to which source the port we opened is associated. So passing `$default_source_url` as recursion in the fallback case could also lead to strange behavior if the `../..` is fixed. This whole "two directories" approach from above is a little bit of a hack, as this is only a convention we are using now. But actually the PortIndex could define any paths (less or deeper nested). But I don't know if there is a better solution than what we have now. As I implemented this part, I was under the impression that the port URLs for remote indexed port trees are always mapped to file:// locally after fetching. But obviously, this is not the case here. Only portdirs are mapped, not the porturls. As `getportdir` already has conditionals for determining the directory a Portfile is in (or has been fetched to), we could just drop the switch and use `set proposedpath [file normalize [file join [getportdir $url] .. ..]]` for all. I don't have a source tree over HTTP to test this, nor do I know how one is supposed to set one up as there is nothing about that in [http://guide.macports.org The Guide]. Does it only require serving the PortIndex and Portfiles over HTTP? ([http://svn.macosforge.org/repository/macports/trunk/dports/PortIndex like this?]) -- Ticket URL: <http://trac.macports.org/ticket/19338#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS