#47478: octave-stk @2.2.0_0: update to 2.2.1 -----------------------------+--------------------------------- Reporter: mschamschula@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Resolution: | Keywords: haspatch maintainer Port: octave-stk | -----------------------------+--------------------------------- Comment (by michaelld@…): Ok; so here's the actual problems: In octave-1.0 PortGroup, we set "pkg prefix ${prefix}/share/octave/packages ${prefix}/lib/octave/packages", which (according to "octave> help pkg") puts non-arch files into the former directory and arch-specific files into the latter directory. For most packages, this separation is not an issue -- or, more likely, there is no real separation so it's a non-issue. But, for this new STK it is an issue & you can verify that the binaries do end up in lib while the m-scripts end up in share. STK works only when all of these files are in the same directory structure -- PKG_ADD and PKG_DEL make this clear -- but it probably won't be difficult to work around this if we really wanted to. So, STK is at fault here, assuming that all of its files will be installed into the same directory structure while octave offers alternatives. That said, there's more to this issue, too. The cruft part happens because octave does not always perform cleanup properly when the prefix is defined as above -- sometimes it does and sometimes it does not (not clear to me when/why). So, removing cruft is important, but not sufficient to get STK working. I think the best solution is to just install all pkg files into either lib or share, and not separate the arch and non-arch files out -- no matter how attractive this might be. Doing this solves 2 problems: 1) packages like STK will work; 2) octave should properly clean up packages when uninstalling/deactivating them (but, we can leave the cruft remover for legacy use of this PortGroup). Doing this is a simple change to the octave-1.0 PortGroup, and since all of the other packages work then we don't need to rev-bump them; they will get moved as they get updated. What fun! -- Ticket URL: <https://trac.macports.org/ticket/47478#comment:10> MacPorts <https://www.macports.org/> Ports system for OS X