macports versions > 1.6, error with http repositories

[mirko.bordignon@…]

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

[jmroot (Joshua Root)]

Actually it's broken for anything other than a ​file:// URL that doesn't have a _resources dir. Raim, does this patch look OK?

[raimue (Rainer Müller)]

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 ​The Guide. Does it only require serving the PortIndex and Portfiles over HTTP? (​like this?)

[jmroot (Joshua Root)]

As far as I can tell, this stuff is working correctly again as of r53740.

[cooljeanius (Eric Gallager)]

Cc Me!