[MacPorts] #36977: linkchecker @8.1_0 Destroot error on OS X 10.8.2
#36977: linkchecker @8.1_0 Destroot error on OS X 10.8.2 --------------------------+-------------------------------- Reporter: gcasiraghi@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: mountain | Port: linkchecker @8.1_0 --------------------------+-------------------------------- port install fails with the following (partial) message: {{{ ---> Staging linkchecker into destroot Error: org.macports.destroot for port linkchecker returned: app.executable linkchecker-gui does not exist }}} All dependencies installed (active): {{{ makeicns @1.4.10a graphics/makeicns py27-pyqt4 @4.9.5 python/py-pyqt4 python27 @2.7.3 lang/python27 xz @5.0.4 archivers/xz }}} Build system: Xcode Version 4.5.2 (4G2008a) on OS X 10.8.2. Attached the log file for port linkchecker (/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_linkchecker/linkchecker/main.log). -- Ticket URL: <https://trac.macports.org/ticket/36977> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36977: app portgroup can fail when used with python portgroup ---------------------------+-------------------------- Reporter: gcasiraghi@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: app | ---------------------------+-------------------------- Changes (by ryandesign@…): * cc: openmaintainer@… (removed) * keywords: mountain => * port: linkchecker @8.1_0 => app * owner: macports-tickets@… => ryandesign@… Comment: When the app portgroup was initially added to the linkchecker port in r83054, the port was using the python27 portgroup. The python27 portgroup was included first, so its post-destroot proc was included first and therefore ran first, setting up the symlinks to the executables, including the linkchecker-gui symlink. The app portgroup was included second, so its post-destroot proc was included second and ran second, which checked for the existence of linkchecker-gui before allowing it to be used as the executable of the application wrapper. But in r99462 the linkchecker port was updated to 8.1 and the portgroup was changed from python27 to python. The python portgroup works differently and does not define its post-destroot proc right away; it waits until python.versions gets set. By that time the app portgroup's post-destroot proc has already been included. So now the app portgroup's post-destroot proc is running first, and failing, because the program it expects to be there (the linkchecker-gui symlink) hasn't been created yet. This sounds like a problem that would affect other ports wanting to use both the python and app portgroups, and is not specific to the linkchecker port. The only other port currently using both the python and app portgroups is tortoisehg, but it is not affected because its app executable is a file in workpath. The solution could be to make the app portgroup wait to define its post- destroot proc until app.executable is set. Portfile authors typically define python.versions before dependencies are declared, so that ${python.version} can be used in the dependency names, while the app portgroup's keywords are typically defined further down, near where other destroot-phase operations happen. This would also have the advantage of making the order of portgroup inclusion irrelevant. -- Ticket URL: <https://trac.macports.org/ticket/36977#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36977: app portgroup can fail when used with python portgroup ---------------------------+-------------------------- Reporter: gcasiraghi@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: app | ---------------------------+-------------------------- Comment (by jmr@…): You can't rely on pre/post procs running in a specific order, just as you can't rely on variants being executed in a specific order. However the source file doesn't need to exist to create a symlink, so you could probably just remove the existence checks. Alternatively, document that the app.* files must be created before post-destroot. In this case, the executable is itself a symlink, so you could solve the problem just by referencing the source file rather than the link. -- Ticket URL: <https://trac.macports.org/ticket/36977#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36977: app portgroup can fail when used with python portgroup ---------------------------+-------------------------- Reporter: gcasiraghi@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: app | ---------------------------+-------------------------- Comment (by ryandesign@…): Why can't I rely on the procs running in the defined order? They seem to run in that order. Why would we break that now? The purpose of the existence checks in the portgroup is to assist portfile developers in using the portgroup correctly, to sort of make the portgroup self-documenting. You may be right that we should just require the file to exist before post-destroot and use the real file instead of the symlink. I think the only reason I didn't do that in the first place is using the symlink looked prettier (shorter) in the portfile, but that hardly matters. -- Ticket URL: <https://trac.macports.org/ticket/36977#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36977: linkchecker: destroot fails after switching to python portgroup ---------------------------+-------------------------- Reporter: gcasiraghi@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: fixed | Keywords: Port: linkchecker | ---------------------------+-------------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => fixed * port: app => linkchecker Comment:
In this case, the executable is itself a symlink, so you could solve the problem just by referencing the source file rather than the link.
r99836. P.S: I meant to mention it before: [wiki:FAQ#portlist "port list" doesn't do what you think it does]. -- Ticket URL: <https://trac.macports.org/ticket/36977#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts