Projects
New Ticket     Wiki     Browse Source     Timeline     Roadmap     Bug Reports     Search

Ticket #10768 (closed defect: fixed)

Opened 2 years ago

Last modified 4 months ago

BUG: port - dependency passes by inexisting ports

Reported by: yves@… Owned by: eridius@…
Priority: High Milestone: MacPorts 1.6.1
Component: base Version:
Keywords: dependency haspatch Cc: markd@…, ricci@…, jmr@…
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

bad_dep.diff (497 bytes) - added by jmr@… 4 months ago.
fix

Change History

Changed 2 years ago by markd@…

  • summary changed from port: dependency passes by inexisting ports to BUG: port - dependency passes by inexisting ports

I've noticed that too.

Changed 18 months ago by pipping@…

  • milestone set to MacPorts 1.4

Changed 18 months ago by jmpp@…

  • owner changed from darwinports-bugs@… to macports-dev@…
  • priority changed from Nice to have to Important
  • milestone changed from MacPorts 1.4 to Needs developer review

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

Changed 16 months ago by eridius@…

  • owner changed from macports-dev@… to eridius@…

Changed 16 months ago by eridius@…

  • status changed from new to assigned

Changed 15 months ago by eridius@…

  • cc yves@… added
  • status changed from assigned to closed
  • resolution set to worksforme

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.

Changed 13 months ago by jmpp@…

  • milestone changed from Needs developer review to MacPorts base bugs

Milestone Needs developer review deleted

Changed 13 months ago by nox@…

  • cc yves@…, markd@…, eridius@… added; yves@… removed
  • priority changed from Important to High
  • version 1.3.2 deleted

Changed 13 months ago by nox@…

  • milestone changed from MacPorts base bugs to MacPorts base enhancements

Changed 13 months ago by nox@…

  • type changed from enhancement to defect
  • milestone changed from MacPorts base enhancements to MacPorts base bugs

Sorry, I've modified the wrong field.

Changed 7 months ago by ricci@…

  • status changed from closed to reopened
  • resolution worksforme deleted

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).

Changed 7 months ago by ricci@…

  • cc ricci@… added

Changed 5 months ago by eridius@…

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.

Changed 4 months ago by jmr@…

  • cc jmr@… added; yves@…, eridius@… removed
  • milestone changed from MacPorts base bugs to MacPorts 1.6.1

Nominating for the upcoming release.

Changed 4 months ago by jmr@…

fix

Changed 4 months ago by jmr@…

  • keywords haspatch added

Changed 4 months ago by jmr@…

  • status changed from reopened to closed
  • resolution set to fixed

I went ahead and committed the fix in r36648.

Note: See TracTickets for help on using tickets.