Opened 12 years ago
Last modified 4 years ago
#36612 new defect
path:-style dep allows non-macports file inside macports prefix
| Reported by: | nerdling (Jeremy Lavergne) | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | base | Version: | 2.1.99 |
| Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt) | |
| Port: |
Description
When MacPorts encounters a path:-style dependency, it will allow a non-MacPorts file that is within the MacPorts prefix to satisfy the installation. This doesn't make sense, since MacPorts should be master of its own directories. Logs are attached showing that a package is not installed, yet its files are found and used inside the MacPorts prefix.
This most prevalent cause of this problem is someone installing a dmg/pkg from MacPorts, which will install files right into the MacPorts prefix by default.
MacPorts might also consider cowardly failing if there's an attempt to generate a dmg/pkg using the default prefix.
Attachments (2)
Change History (4)
Changed 12 years ago by nerdling (Jeremy Lavergne)
Changed 12 years ago by nerdling (Jeremy Lavergne)
| Attachment: | pspp-devel.log added |
|---|
gtk2 was installed without pango/cairo because it found their files already inside the prefix
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to snc@…:
When MacPorts encounters a path:-style dependency, it will allow a non-MacPorts file that is within the MacPorts prefix to satisfy the installation. This doesn't make sense, since MacPorts should be master of its own directories. Logs are attached showing that a package is not installed, yet its files are found and used inside the MacPorts prefix.
This most prevalent cause of this problem is someone installing a dmg/pkg from MacPorts, which will install files right into the MacPorts prefix by default.
#36482 was another recent case of this.
MacPorts might also consider cowardly failing if there's an attempt to generate a dmg/pkg using the default prefix.
That would prevent us from creating MacPorts releases. :) A warning about this would be good though. Or an error, and a flag needed to override it. Or, special-case the "MacPorts" port. In any case this should be a separate ticket.
comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to nerdling:
When MacPorts encounters a path:-style dependency, it will allow a non-MacPorts file that is within the MacPorts prefix to satisfy the installation. This doesn't make sense, since MacPorts should be master of its own directories
What do you suggest that MacPorts should do instead? If we attempt to install the port that should provide those files, activating the port will fail because the files it wants to install already exist.
gtk2 configure failed because of missing programs