#50528 closed defect (fixed)
logwatch: does not properly delete old unregistered /opt/local/bin/logwatch symlink
| Reported by: | dbevans (David B. Evans) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.3.4 |
| Keywords: | Cc: | kurthindenburg (Kurt Hindenburg) | |
| Port: | logwatch |
Description
Fails during activation as follows:
Error: org.macports.activate for port logwatch returned: Image error: /opt/local/bin/logwatch already exists and does not belong to a registered port. Unable to activate port logwatch. Use 'port -f activate logwatch' to force the activation. DEBUG: Error code: registry::image-error DEBUG: Backtrace: Image error: /opt/local/bin/logwatch already exists and does not belong to a registered port. Unable to activate port logwatch. Use 'port -f activate logwatch' to force the activation.
I'm guessing this is a copy installed as part of the buildbot infrastructure? If so perhaps this should be installed in a different location such as /usr/local.
Change History (3)
comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | khindenburg@… added |
|---|---|
| Component: | server/hosting → ports |
| Resolution: | → fixed |
| Status: | new → closed |
| Summary: | logwatch: build fails on all buildbots during activation → logwatch: does not properly delete old unregistered /opt/local/bin/logwatch symlink |
comment:2 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
I wrote up this solution in PortfileRecipes#symlink-exists.
Note: See
TracTickets for help on using
tickets.
No parts of the buildbot slave infrastructure are installed in /opt/local. /opt/local is under the control of the buildbot, for building MacPorts packages.
The problem affects user systems as well, not just the buildbot machines.
This is a bug in the logwatch portfile. It used to directly install the /opt/local/bin/logwatch symlink, bypassing the destroot. This was fixed in r127811 and r127812 to correctly install the symlink as part of the destroot, but for existing installations the old unregistered symlink remained, preventing upgrades from activating correctly, as you've seen.
Attempts were made to fix this in r127815 and r127816 but the attempts were incorrect. The most recent attempted fix doesn't work as intended because it uses
file existsto check for the file's existence, butfile existsresolves symlinks, so it is actually checking if the file the symlink points to exists, which it doesn't, so it doesn't get deleted. The existence of the symlink itself needs to be tested.I fixed this for logwatch in r145392 the same way I had fixed it for nedi in r143403.