Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#44909 closed update (fixed)

fswatch @1.4.3 update

Reported by: emcrisostomo (Enrico Maria Crisostomo) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.3.1
Keywords: haspatch maintainer Cc:
Port: fswatch

Description


Attachments (1)

dbdff4e71c73680d01b479a6875e809f8023cde0.diff (1.1 KB) - added by emcrisostomo (Enrico Maria Crisostomo) 10 years ago.

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by emcrisostomo (Enrico Maria Crisostomo)

comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: Thanks. added
Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned

comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: Thanks. removed

The port installs a broken symlink:

lrwxr-xr-x  1 root  wheel     130 Sep  7 19:44 /opt/local/bin/fswatch-run -> /opt/local/var/macports/build/_Users_rschmidt_macports_dports_sysutils_fswatch/fswatch/work/destroot/opt/local/bin/fswatch-run-zsh

Can this be fixed?

comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

Actually it was easy to fix. Included in the update in r125150. Filed upstream bug report.

comment:4 Changed 10 years ago by emcrisostomo (Enrico Maria Crisostomo)

Hi ryandesign@…, but although the patch you applied works for MacPorts, it breaks the functionality of DESTDIR installs. In fact, as I already explained in the issue you opened in fswatch repository here (https://github.com/emcrisostomo/fswatch/issues/54), this patch breaks DESTDIR installs (that's why the DESTDIR variable is there, in the first place). Why it does not work correctly in MacPorts, I do not know, and that's something I'd ask somebody here at MacPorts to check.

I do not know whether I should ask for this ticket to be opened again or whether to submit another ticket.

Thank you, -- Enrico

comment:5 in reply to:  4 Changed 10 years ago by larryv (Lawrence Velázquez)

Replying to enrico.m.crisostomo@…:

I do not know whether I should ask for this ticket to be opened again or whether to submit another ticket.

Neither. This is an upstream problem.

comment:6 Changed 10 years ago by emcrisostomo (Enrico Maria Crisostomo)

Hi larryv, I'm fswatch author and my point is that patch is wrong in the first place. The patch, removing $DESTDIR variable from a Makefile hook, results in the link pointing to /usr/local/bin even when performing a DESTDIR install, which IMHO is plain wrong.

That's why I ask what should be done in a MacPorts port file. Performing a DESTDIR install and expecting symbolic links to point to another location as if DESTDIR weren't specified makes no sense to me.

Thanks for your help.

Version 0, edited 10 years ago by emcrisostomo (Enrico Maria Crisostomo) (next)

comment:7 Changed 10 years ago by emcrisostomo (Enrico Maria Crisostomo)

Hi larryv@…,

I was checking the Automake literature and funnily enough, page 131 of the latest Automake manual agrees literally with the original sources:

For instance, here is how to create a hard link to an installed program:
     install-exec-hook:
             ln $(DESTDIR)$(bindir)/program$(EXEEXT) \
                $(DESTDIR)$(bindir)/proglink$(EXEEXT)

If the link is broken after the package is built and moved into place, I really don't know why, and I'm inclined to think it's a MacPorts peculiarity, if not quirk. And since I'm no MacPorts experts, I'm asking for help here.

Thanks again.

comment:8 in reply to:  7 Changed 10 years ago by larryv (Lawrence Velázquez)

I’ve commented on the upstream issue. There is no MacPorts problem here; you’re simply using DESTDIR where you should be using prefix.

comment:9 Changed 10 years ago by emcrisostomo (Enrico Maria Crisostomo)

Thanks larryv, I just answered you on that issue: I see the problem. I'll fix the Makefile upstream and I'll push another Portfile.

comment:10 in reply to:  7 Changed 10 years ago by larryv (Lawrence Velázquez)

Replying to enrico.m.crisostomo@…:

I was checking the Automake literature and funnily enough, page 131 of the latest Automake manual agrees literally with the original sources:

For instance, here is how to create a hard link to an installed program:
     install-exec-hook:
             ln $(DESTDIR)$(bindir)/program$(EXEEXT) \
                $(DESTDIR)$(bindir)/proglink$(EXEEXT)

If the link is broken after the package is built and moved into place, I really don't know why, and I'm inclined to think it's a MacPorts peculiarity, if not quirk. And since I'm no MacPorts experts, I'm asking for help here.

This is understandably confusing. Note that the bit that you quoted from the Automake manual is for making a hard link, not a symbolic link. A hard link does not break if the source is moved, but a symbolic one does. Indeed, the example must use the DESTDIR’d source because the final source file does not exist when the install-exec-hook target is run.

Last edited 10 years ago by larryv (Lawrence Velázquez) (previous) (diff)
Note: See TracTickets for help on using tickets.