#19338: macports versions > 1.6, error with http repositories --------------------------------------+------------------------------------- Reporter: mirko.bordignon@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.7.1 Keywords: | Port: --------------------------------------+------------------------------------- Changes (by raimue@…): * cc: raimue@… (added) Old description:

Installing any port from an http repository overriding the default one (i.e., coming before it in sources.conf) fails: the only case in the switch body inside the macports::getportresourcepath procedure is not executed, therefore the proposedpath variable is not created and its subsequent manipulation "set proposedpath [file join $proposedpath _resources $path]" fails.

Example output: DEBUG: can't read "proposedpath": no such variable while executing "file join $proposedpath _resources $path" (procedure "macports::getportresourcepath" line 13) invoked from within "getportresourcepath $porturl "port1.0/variant_descriptions.conf"" (procedure "variant_desc" line 4) invoked from within "variant_desc $porturl $variant_provides" (procedure "variant" line 43) invoked from within "variant svn {

... (details removed)

(file "Portfile" line 20) invoked from within "source Portfile" invoked from within "$workername eval source Portfile" (procedure "mportopen" line 46) invoked from within "mportopen $porturl [array get options] [array get variations]" Error: Unable to open port: can't read "proposedpath": no such variable

New description: Installing any port from an http repository overriding the default one (i.e., coming before it in sources.conf) fails: the only case in the switch body inside the macports::getportresourcepath procedure is not executed, therefore the proposedpath variable is not created and its subsequent manipulation "set proposedpath [file join $proposedpath _resources $path]" fails. Example output: {{{ DEBUG: can't read "proposedpath": no such variable while executing "file join $proposedpath _resources $path" (procedure "macports::getportresourcepath" line 13) invoked from within "getportresourcepath $porturl "port1.0/variant_descriptions.conf"" (procedure "variant_desc" line 4) invoked from within "variant_desc $porturl $variant_provides" (procedure "variant" line 43) invoked from within "variant svn { ... (details removed) (file "Portfile" line 20) invoked from within "source Portfile" invoked from within "$workername eval source Portfile" (procedure "mportopen" line 46) invoked from within "mportopen $porturl [array get options] [array get variations]" Error: Unable to open port: can't read "proposedpath": no such variable }}} -- -- Ticket URL: <http://trac.macports.org/ticket/19338#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#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