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)

gtk2.log (18.4 KB) - added by nerdling (Jeremy Lavergne) 12 years ago.
gtk2 configure failed because of missing programs
pspp-devel.log (98.6 KB) - added by nerdling (Jeremy Lavergne) 12 years ago.
gtk2 was installed without pango/cairo because it found their files already inside the prefix

Download all attachments as: .zip

Change History (4)

Changed 12 years ago by nerdling (Jeremy Lavergne)

Attachment: gtk2.log added

gtk2 configure failed because of missing programs

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 in reply to:  description 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 in reply to:  description 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.

Note: See TracTickets for help on using tickets.