Opened 10 years ago

Closed 10 years ago

Last modified 6 years ago

#19338 closed defect (fixed)

macports versions > 1.6, error with http repositories

Reported by: mirko.bordignon@… Owned by: jmroot (Joshua Root)
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version: 1.7.1
Keywords: Cc: raimue (Rainer Müller), cooljeanius (Eric Gallager)

Description (last modified by raimue (Rainer Müller))

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

Attachments (1)

getportresourcepath.diff (1.2 KB) - added by jmroot (Joshua Root) 10 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 10 years ago by raimue (Rainer Müller)

Cc: raimue@… added
Description: modified (diff)

comment:2 Changed 10 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.8.0
Owner: changed from macports-tickets@… to jmr@…
Status: newassigned

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

Changed 10 years ago by jmroot (Joshua Root)

Attachment: getportresourcepath.diff added

comment:3 Changed 10 years ago by 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?)

comment:4 Changed 10 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: assignedclosed

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

comment:5 Changed 6 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.