[MacPorts] #47478: octave-stk @2.2.0_0: update to 2.2.1

[MacPorts]

#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