#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) | |
Port: |
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)
Change History (6)
comment:1 Changed 15 years ago by raimue (Rainer Müller)
Cc: | raimue@… added |
---|---|
Description: | modified (diff) |
comment:2 Changed 15 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future → MacPorts 1.8.0 |
---|---|
Owner: | changed from macports-tickets@… to jmr@… |
Status: | new → assigned |
Changed 15 years ago by jmroot (Joshua Root)
Attachment: | getportresourcepath.diff added |
---|
comment:3 Changed 15 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 15 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
As far as I can tell, this stuff is working correctly again as of r53740.
Actually it's broken for anything other than a file:// URL that doesn't have a _resources dir. Raim, does this patch look OK?