[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 julien.bect@…):

 Replying to [comment:10 michaelld@…]:
 > 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.


 Hello Michael, hello Marius,

 Actually, stk is supposed to behave like a standard octave package...
 Please report any non-standard behaviour as a bug on Octave Forge bug
 tracker:

 https://savannah.gnu.org/bugs/?func=additem&group=octave

 Concerning the DESCRIPTION file which is mentioned above: if you can
 please you tell me in which way it is non-standard, I will fix it right
 away.

 Concerning the directory structure: stk supports, like any other octave
 forge package, the separation of its files between an arch-independent and
 an arch-dependent directory.

 I believe that (part of ?) the problems that you have in creating a binary
 package for MacPorts come in fact from a deeper bug in the octave function
 'pkg' which is reported here:

 https://savannah.gnu.org/bugs/index.php?45369

 See

 https://savannah.gnu.org/bugs/?45091

 for more information.

 @++
 Julien (stk maintainer)

-- 
Ticket URL: <https://trac.macports.org/ticket/47478#comment:12>
MacPorts <https://www.macports.org/>
Ports system for OS X