Opened 18 years ago
Closed 17 years ago
#10768 closed defect (fixed)
BUG: port - dependency passes by inexisting ports
Reported by: | yves@… | Owned by: | kballard (Lily Ballard) |
---|---|---|---|
Priority: | High | Milestone: | MacPorts 1.7.0 |
Component: | base | Version: | |
Keywords: | dependency haspatch | Cc: | markd@…, ghosthound, jmroot (Joshua Root) |
Port: |
Description
I just found out that if a port: depends is targetted at a port that does not exists, the build will go on as if all was ok.
stange behaviour ...
Attachments (1)
Change History (17)
comment:1 Changed 18 years ago by markd@…
Summary: | port: dependency passes by inexisting ports → BUG: port - dependency passes by inexisting ports |
---|
comment:2 Changed 18 years ago by pipping@…
Milestone: | → MacPorts 1.4 |
---|
comment:3 Changed 18 years ago by jmpalacios (Juan Manuel Palacios)
Milestone: | MacPorts 1.4 → Needs developer review |
---|---|
Owner: | changed from darwinports-bugs@… to macports-dev@… |
Priority: | Nice to have → Important |
Probably MacPorts should bail out claiming the requested port <bogus_port> does not exist and therefore cannot complete installation of port <valid_port_that_listed_bogus_port_in_its_dependency_list>. However, I do not know where the culprit for this behavior could be, therefore setting it to the "needs dev review" milestone.
-jmpp
comment:4 Changed 18 years ago by kballard (Lily Ballard)
Owner: | changed from macports-dev@… to eridius@… |
---|
comment:5 Changed 18 years ago by kballard (Lily Ballard)
Status: | new → assigned |
---|
comment:6 Changed 17 years ago by kballard (Lily Ballard)
Cc: | yves@… added |
---|---|
Resolution: | → worksforme |
Status: | assigned → closed |
I just tested and I can't replicate this. If I make a port depend on another one that doesn't exist, I get an error.
Marking this as worksforme, please re-open if you can reproduce this issue with latest trunk.
comment:7 Changed 17 years ago by jmpalacios (Juan Manuel Palacios)
Milestone: | Needs developer review → MacPorts base bugs |
---|
Milestone Needs developer review deleted
comment:8 Changed 17 years ago by nox@…
Cc: | yves@… markd@… eridius@… added; yves@… removed |
---|---|
Priority: | Important → High |
Version: | 1.3.2 |
comment:9 Changed 17 years ago by nox@…
Milestone: | MacPorts base bugs → MacPorts base enhancements |
---|
comment:10 Changed 17 years ago by nox@…
Milestone: | MacPorts base enhancements → MacPorts base bugs |
---|---|
Type: | enhancement → defect |
Sorry, I've modified the wrong field.
comment:11 Changed 17 years ago by ghosthound
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Well well, I just found that this is very reproducible. The current 'perl/p5-mac-apps-launch' port demonstrates this nicely, it contains:
depends_lib-append port:p5-mac-appleevents \
and there is no port named 'p5-mac-appleevents'. I then added to the depends_lib-append list the following line:
port:p5-complete-nonsense-no-way-cant-be
and the port still builds just fine. Neither of the non-existent ports are reported during 'port -v -d build', not even a "DEBUG: Searching for dependency:"... line for either of them.
I tested the non "-append" version of depends_lib in a different port, added an utterly bogus port:BOGUS_NAME_HERE and again, no report of that port being searched for, etc.
Thus I'm certain this bug is present in r33768 (svn up on 20080204), I have not yet tested HEAD (it won't build for me right now).
comment:12 Changed 17 years ago by ghosthound
Cc: | ricci@… added |
---|
comment:13 Changed 17 years ago by kballard (Lily Ballard)
Interesting twist - it seems that if the missing dependency is listed first, it errors out. If it's listed anywhere after first in the list, it's silently ignored.
comment:14 Changed 17 years ago by jmroot (Joshua Root)
Cc: | jmr@… added; yves@… eridius@… removed |
---|---|
Milestone: | MacPorts base bugs → MacPorts 1.6.1 |
Nominating for the upcoming release.
comment:15 Changed 17 years ago by jmroot (Joshua Root)
Keywords: | haspatch added |
---|
comment:16 Changed 17 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I went ahead and committed the fix in r36648.
I've noticed that too.