I use packages prefixes all the time.

- different octave versions
- different packages versions (mainly dev)
- my own order, e.g. ~/.local instead of my home folder

I just tried the new octave_packages build thing (cherry-picked the two related csets into my old & overdue mxe-octave build tree) and it works beautifully.

I hadnt looked at it, but it probally could - I will take a look

I added creation of the octave_packages file as part of the pkg-install.py command, and it seems to work ok for me when using the latest 6.0.0 sources.

https://hg.octave.org/mxe-octave/rev/4eae7db624e8

The mxe-installer file installer-files/post-install.bat still runs the pkg rebuild on install time for those that run the installer and will continue to ensure that the older 5.1 sources still end up with a usable pkg list (at least from the installer, or running the post install script)

When we move to the 6.0 versions, the rebuild can be removed from the post install script.

@Markus:
Thanks for testing & pushing - I didn't expect it to happen that soon :-)

@JohnD:
My current trick is copying over from my Windows partition / installed Octave by a rule in binary-dist-rules.mk
Today I upgraded my desktop box to Mageia 7, reinstalled all build tools and when running a fresh mxe-octave clone I saw:

[check requirements]
/bin/bash: octave: command not found
Warning - could not find native build version 6.0.0 of octave - some packages may fail, but continuing
:

....so the mxe-octave build tools are already prepared to invoke Octave on Linux in some way.
As most devs simply need a Linux build tree for Octave in the first place (to create the dist archive needed for mxe-octave) I figure a simple rule in Makefile.in could do the trick.

The octave_packages file is simply a text .mat file, ideally written by Octave itself.
One doesn't even need a current Octave when cross-building dev Octave; if one adds <mxe-octave>/.../mingw64/share/octave/6.0.0/m/pkg to the path the installed Octave (on Linux) will use the most recent scripts.
"pkg rebuild" is a pretty straightforward function that merely scans the package install directory (m-files) and adds the found package directories + related lib/octave/<arch>/ package directories + other info to the packages cellstruct. It doesn't run any of the functions so this is fairly safe.

Taking a quick look, it should be pretty easy to add to the existing script, so I will take a look today or tommorrow unless someone else beats me to it

Here are two csets.

The first (bug_51632_3rd_fix_global_OCTAVE_HOME.cset) is the fix for the original issue, i.e.,

• when writing the octave_packages file it replaces the OCTAVE_HOME part of packages installation paths with "__OH__"
• when reading the octave_packages file it replaces "__OH__" with the then current OCTAVE_HOME contents.

This fix make Octave completely relocatable; I tried on Windows, but AFAICS it should also work on Linux.

The other cset (bug_51632_list_global_OCTAVE_HOME.cset) is for cosmetics, it replaces the OCTAVE_HOME part of package installation files with <OCTAVE_HOME> when running "pkg list", and is independent of the first cset. See below for an example.
Before:

>> pkg list
Package Name         | Version | Installation directory
---------------------+---------+-----------------------
     communications  |   1.2.1 | ...\mingw64\share\octave\packages\communications-1.2.1
            control *|   3.1.0 | ...\OCTAVE~1.0\mingw64\share\octave\packages\control-3.1.0
           database  |   2.4.3 | ...\OCTAVE~1.0\mingw64\share\octave\packages\database-2.4.3
:

After:

>> pkg list
Package Name         | Version | Installation directory
---------------------+---------+-----------------------
     communications  |   1.2.1 | <OCTAVE_HOME>\share\octave\packages\communications-1.2.1
            control *|   3.2.0 | <OCTAVE_HOME>\share\octave\packages\control-3.2.0
     data-smoothing  |   1.3.0 | <OCTAVE_HOME>\share\octave\packages\data-smoothing-1.3.0
:

The fix here (replacing just the OCTAVE_HOME parts) will work for the vast majority of the Octave installations. I've been busy with replacing the prefix/archprefix parts as well but that is a bit more complicated. Later on I'll come up with a fix that builds on top of the ones here.

I think the patches here are ready to be applied.

A related question is how to get an octave_packages file in mxe-octave. One way would be to have a local Octave installation on the build system (Linux) and use that with a script to generate the octave_packages file, along the lines of:
 
1. "pkg prefix" and "pkg archprefix" pointing to the octave installation in <mxe-octave>/dist/octave/mingw64

2. "pkg global_list" to specify where the octave_packages file needs to be created (<mxe-octave>/dist/octave/mingw64/share/octave)

3. "pkg rebuild" to actually create the octave-packages file.


(file #47875, file #47876)

Imho, it would probably be best to open a dedicated bug report for the short file names vs. long file names issue and not re-purpose one of the existing bugs.

I was referring to the "canonicalize_file_name" usages in the patch for this bug  here. But it might well be that some of the ones in the other patch can be dropped as well.

Thanks for trying.

To stop thread drift (due to myself in the first place :-) ) shall we continue the discussion on e.g., bug #56267? (as that's where the fix was made that uncovered all the rest of the 8.3 vs. LFN issues.)
Or any other bug report that seems better suited.

Perhaps bug #57083, that has been closed but I'll reopen as soon as I find that indeed some canonicalize_file_name() calls can be dropped (comment #41 here).

Here the log with Octave 5.1.0:

>> ver
----------------------------------------------------------------------
GNU Octave Version: 5.1.0 (hg id: d05d6eebde10)
GNU Octave License: GNU General Public License
Operating System: MINGW32_NT-6.2 Windows 6.2  x86_64
----------------------------------------------------------------------
Package Name         | Version | Installation directory
---------------------+---------+-----------------------
     communications  |   1.2.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\communications-1.2.1
            control  |   3.1.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\control-3.1.0
     data-smoothing  |   1.3.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\data-smoothing-1.3.0
           database  |   2.4.3 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\database-2.4.3
          dataframe  |   1.2.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\dataframe-1.2.0
              dicom  |   0.2.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\dicom-0.2.1
          financial  |   0.5.3 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\financial-0.5.3
               fits  |   1.0.7 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\fits-1.0.7
fuzzy-logic-toolkit  |   0.4.5 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\fuzzy-logic-toolkit-0.4.5
                 ga  |  0.10.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\ga-0.10.0
            general  |   2.1.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\general-2.1.0
      generate_html  |   0.3.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\generate_html-0.3.1
           geometry  |   3.0.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\geometry-3.0.0
                gsl  |   2.1.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\gsl-2.1.1
              image  |  2.10.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\image-2.10.0
 instrument-control  |   0.3.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\instrument-control-0.3.1
           interval  |   3.2.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\interval-3.2.0
                 io  |  2.4.12 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\io-2.4.12
     linear-algebra  |   2.2.2 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\linear-algebra-2.2.2
               lssa  |   0.1.3 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\lssa-0.1.3
              ltfat  |   2.3.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\ltfat-2.3.1
            mapping  |   1.2.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\mapping-1.2.1
   mfile_basic_test  |   0.1.0 | C:\Users\Markus\AppData\Local\Temp\oct-G6lQc0\mfile_basic_test-0.1.0
 mfile_minimal_test  |   0.1.0 | C:\Users\Markus\octave\mfile_minimal_test-0.1.0
      miscellaneous  |   1.2.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\miscellaneous-1.2.1
                nan  |   3.1.4 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\nan-3.1.4
             netcdf  |  1.0.12 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\netcdf-1.0.12
              nurbs  |  1.3.13 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\nurbs-1.3.13
                ocs  |   0.1.5 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\ocs-0.1.5
             odepkg  |   0.8.5 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\odepkg-0.8.5
              optim  |   1.5.3 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\optim-1.5.3
        optiminterp  |   0.3.5 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\optiminterp-0.3.5
         quaternion  |   2.4.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\quaternion-2.4.0
           queueing  |   1.2.6 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\queueing-1.2.6
             signal  |   1.4.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\signal-1.4.0
            sockets  |   1.2.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\sockets-1.2.0
          sparsersb  |   1.0.6 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\sparsersb-1.0.6
            specfun  |   1.1.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\specfun-1.1.0
            splines  |   1.3.2 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\splines-1.3.2
         statistics  |   1.4.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\statistics-1.4.0
                stk  |   2.5.1 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\stk-2.5.1
            strings  |   1.2.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\strings-1.2.0
             struct  |  1.0.15 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\struct-1.0.15
             tisean  |   0.2.3 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\tisean-0.2.3
                tsa  |   4.4.5 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\tsa-4.4.5
              video  |   1.2.4 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\video-1.2.4
            windows  |   1.3.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\windows-1.3.0
             zeromq  |   1.3.0 | D:\Octave\Octave-5.1.0.0\mingw64\share\octave\packages\zeromq-1.3.0
>> OCTAVE_HOME
ans = D:\Octave\Octave-5.1.0.0\mingw64
>> diary off

So the conversion to 8.3 file names seems to be a no-op on that drive.

Sorry for the German link. Here the English version:
https://support.microsoft.com/en-us/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions

BTW I see a bit of thread drift.

This bug / feature request is about making pkg.m deal with relocation, not so much LFN. Hopefully one of the core devs will pick up.

Also on a more general note: I don't think that we should rely on the short file names to fix bugs at all. Support for short file names is optional for NTFS. Indeed, I had to attach an external NTFS volume for testing because the file systems on my internal volumes don't seem to store short file names.
Windows 10 came pre-installed. Maybe this is a new default - or some oddity of the manufacturer (ASUS).

Markus, I think there's little wrong with your fix for bug #56267.

An issue is that all over the place in Octave we have a mix of "8.3" and LFN style paths.

One way to tackle that would be to deal with all 8.3 pathnames in one fell swoop, but that could defeat the very purpose they were created for.
The other tactic would be to just wait until more bugs pop up caused by mixing the path name styles on Windows. We'd need to keep track of where that is, as one fine day all those canonicalize_file_name () calls might be dropped.

My vote is for the latter option :-)

We can try to proactively grep for places where pathnames are compared. I suspect that number will be limited and I think we already got most of them.

@Markus:
The issue is no so much rmdir() but rather rmpath() that was handed 8.3 style pathnames but obviously couldn't match them with the LFN ones that appear now in the search path.
I see that on Windows, at various places in the code, 8.3 style pathnames still pop up, probably all originating from __octave_config_info__ .
In itself that's not so much a problem but since your cset 27497:5a0543de1e47 "Add canonical path when using addpath (bug #56267)", canonicalize_file_name calls are due in several places in the code that deal with paths.
A bit confusing is that all OF packages now have LFN pathnames in the path but core Octave functions still have 8.3 ones:

:
D:\Octave\Octave-6.0.0_20191031L\mingw64\share\octave\packages\io-2.4.13
D:\Octave\Octave-6.0.0_20191031L\mingw64\lib\octave\packages\io-2.4.13\x86_64-w64-mingw32-api-v53+
:
:
D:\Octave\OCTAVE~1.0_2\mingw64\lib\octave\6.0.0\site\oct\x86_64-w64-mingw32\
D:\Octave\OCTAVE~1.0_2\mingw64\lib\octave\site\oct\api-v53+\x86_64-w64-mingw32
:
:
D:\Octave\OCTAVE~1.0_2\mingw64\share\octave\6.0.0\m\general
:

Was a little different, in fact rmpath() didn't recognize the 8.3 style path name it was handed by doc_cache_create, but another canonicalize-file_name() solved the issue.

Second cset attached, AFAICS this one works w/o errors on Windows and Linux for install, uninstall, load, unload, rebuild & describe.


(file #47769)

Here's a first cset, aimed at replacing OCTAVE_HOME in the paths in the global octave-packages file.
It works mostly fine, but it's perhaps it's presently more a proof-of-concept.

It has been tested on Windows and Linux.
In Windows I ran Octave directly from the <mxe-octave>/dist/octave... installation, being able to use all prebuilt package still residing on the (read-only mounted) linux partition. To do that I simply copied the octave-packages file from Windows over to <mxe-octave>/dist/octave/mingw64/share/octave/ (did that in Linux where I can mount the Windows drive read-only) and back in Windows made a shortcut to the octave.vbs file in said mxe-octave installation tree.

So I think that proves that the global octave_packages is now relocatable.

I saw one glitch:
While trying to install the econometrics-1.1.2 package on Windows I ran into error messages about doc building. IIRC ?gen_lookfor_cache? or so? still used the 8.3 style paths and complained about some path or file not found - sorry I didn't save the messages (was late at night :-) )
In the end the search path contained entries for (IIRC) .../econometrics-1.1.2/doc and econometrics-1.1.2/packinfo
IIRC restarting Octave and a "pkg rebuild" solved it.

Comments welcome.

(file #47765)

I would be in support of that. Since OCTAVE_HOME is already set on launch it would make this a non issue.

FYI, separate wishlist bug report created at bug #51684 for a truly portable" version.

Doug makes an interesting point; the need for a pkg rebuild is less a 'at first launch' issue, but more of a 'whenever you change computer by treating the zip version as a portable octave' issue. Therefore it might make less sense to rely on the presence or absence of an `octave_packages` file, and more sense to simply check (via octaverc) whether `pkg list` is displaying appropriate output at each launch, and attempt a pkg rebuild if it is not, under the assumption that the paths have changed.

On the other hand, it would be reasonable to expect that a user that treats the octave zip-version "portably" in this way, is likely aware of the need to do a pkg rebuild, once they've done it once, and that this is a trivial thing to do so ... therefore to me this is still a documentation-first issue. It's an extremely simple issue to address, once you know what's going on. The biggest obstacle is not knowing what's going on in the first place, and not being aware of the relevant wiki post (as per the original stackoverflow post that triggered this discussion).

I feel the solution is more along the lines of having a simple line saying "you may need to rebuild / upgrade the packages", or a link to the wiki, next to the download link to the zipped version; this could also clarify what Mike is saying at the point of download, e.g. "link to alternative zip version: use this if you're looking for a standalone version that doesn't require admin rights, or to use as a 'portable' distribution (but see point on wiki regarding portability)". I think the fact that the download link in the main website simply redirects to a dry webpage of ftp links instead, devoid of any helpful instructions, is more relevant to the problem than an octaverc fix, however nice a touch the latter would be.

Before I retired I had octave installed on a memory stick, and I carried it with me to different rooms. I then inserted the memory stick in whatever computer was in the room. I found that I had to do a rebuild so that the drive letter would work in that room. Each computer seemed to assign a different drive letter to the usb slot that I plugged the memory  stick into. I don't know if this is the same issue but it might be related, and I don't know how many people would still be doing it this way.

Why would relative vs absolute paths even be an issue here?
All that would need to be done is to modify octaverc in the prepackaged windows zip version specifically such that it runs a simple pkg rebuild command at first launch (as per the one-liner below).
Are we getting sidetracked here, or is there a legitimate reason this would not be the preferred approach?

Also, regardless, it may still be worth treating this issue partly as a documentation issue, and simply make it more visible to a user at first launch; while any programmatic fix might address the `rebuild` issue, the user might still want to be informed that it may be worth to `update` their pkg database too, as per the wiki. And you certainly wouldn't want to automatically trigger an update programmatically at first launch.

for the building of octave_packages file,

cd $(HOST_PREFIX)
OCTAVE_HOME=. octave-cli --eval 'pkg rebuild -global'

appears to create the octave_packages file, with paths now as ./share/octave/packages/commuications-1.2.1 and ./lib/octave/packages/communications-1.2.1, so if the package database worked with names relative to OCTAVE_HOME, I think that would work.

It seems to me that we should just make the package database work with relative directory names so that any directory name that is stored in the file and that is not absolute is assumed to be relative to OCTAVE_HOME.

I guess if there's a desire to remove those two lines from the octaverc after it's done could add:

  cd $(TOP_BUILD_DIR)/dist/share/octave/site/m/startup \
    && sed -i '$ d' octaverc \
    && sed -i '$ d' octaverc

after the zip line. (i'm sure there is a 'delete two lines' syntax for sed, but that's the limit of my knowledge)

comment on the maintainers list mentioned that the code would throw an error every time Octave started if it was on a system where the user didn't have write access to the normal global_list location. Suggested using a try/catch to hide the error.

if (exist(pkg(&quot;global_list&quot;),&quot;file&quot;) == 0)
  try
    pkg rebuild;
  catch
  end_try_catch
endif

or the ultracompact 1 line version:

if (exist(pkg(&quot;global_list&quot;),&quot;file&quot;) == 0), try, pkg rebuild, catch, end_try_catch, endif

looks like this could just be added to the octaverc sitting in mxe-octave. But that would force this change on everyone to fix a problem only occurring in the Windows zip-distribution. Maybe a line could be added to the binary-dist-rules.mk file to append that line(s) to the octaverc file prior to zipping? Or maybe there's a better way to accomplish that?

is there even a time running a pkg rebuild, when global octave_packages is missing, would break something?

sorry, missed your comment #8, John.  I was intermittently changing  both dir and archprefix, mainly because I wasn't sure what archprefix did.

A simpler approach might be to just include the pkg rebuild command in the octaverc that gets executed on first launch. (I have checked this and it works, and it would be a simple bugfix). If there's a way to detect this is the first launch via some sort of flag, and only launch this once, even better; I've noticed there's a separate "octave-fistlaunch.vbs" script in the root folder: perhaps an environment variable can be set that is checked for within octaverc?

Whether there should be some form of documentation to inform of the potential need for a pkg update as well is a slightly separate issue.

I think you changed the wrong path - archprefix, instead of dir.

There is a comment #length that provides info on the length of the value, which has changed as you added the fullpath in.

well, it's the syntax that normally works at the Octave interpreter  in windows (cd $OCTAVE_HOME gives an error, but cd %OCTAVE_HOME% works). Was hopeful it would be transparent to pkg, but no luck.  Would have made this a trivial fix. maybe add it to the ever longer 'pkg improvement wishlist' absent any other workaround...

just to answer my own question: no, currently octave_packages cannot handle variables in paths.

Took my octave_packages file, replaced the absolute paths for the signal package from

C:\Octave\OCTAVE~1.1\lib\octave\packages\signal-1.3.2

to

%OCT_HOME%lib\octave\packages\signal-1.3.2

It renders the entire file unreadable to a 'pkg list'. i.e.:

pkg list:

>> pkg list
Package Name         | Version | Installation directory
---------------------+---------+-----------------------
     communications  |   1.2.1 | ...\share\octave\packages\communications-1.2.1
            control  |   3.0.0 | ...\share\octave\packages\control-3.0.0
     data-smoothing  |   1.3.0 | ...\share\octave\packages\data-smoothing-1.3.0
           database  |   2.4.2 | ...\share\octave\packages\database-2.4.2
          dataframe  |   1.1.0 | ...\share\octave\packages\dataframe-1.1.0
              dicom  |   0.2.0 | ...\share\octave\packages\dicom-0.2.0
          financial  |   0.5.0 | ...\share\octave\packages\financial-0.5.0
               fits  |   1.0.7 | ...\OCTAVE~1.1\share\octave\packages\fits-1.0.7
fuzzy-logic-toolkit  |   0.4.5 | ...\octave\packages\fuzzy-logic-toolkit-0.4.5
                 ga  |  0.10.0 | ...\OCTAVE~1.1\share\octave\packages\ga-0.10.0
            general  |   2.0.0 | ...\share\octave\packages\general-2.0.0
      generate_html  |   0.3.1 | ...\share\octave\packages\generate_html-0.3.1
           geometry  |   3.0.0 | ...\share\octave\packages\geometry-3.0.0
                gsl  |   2.0.0 | ...\OCTAVE~1.1\share\octave\packages\gsl-2.0.0
              image  |   2.6.1 | ...\share\octave\packages\image-2.6.1
 instrument-control  |   0.2.3 | ...\octave\packages\instrument-control-0.2.3
           interval  |   2.1.0 | ...\share\octave\packages\interval-2.1.0
                 io  |   2.4.7 | ...\OCTAVE~1.1\share\octave\packages\io-2.4.7
     linear-algebra  |   2.2.2 | ...\share\octave\packages\linear-algebra-2.2.2
               lssa  |   0.1.2 | ...\OCTAVE~1.1\share\octave\packages\lssa-0.1.2
              ltfat  |   2.2.0 | ...\share\octave\packages\ltfat-2.2.0
            mapping  |   1.2.1 | ...\share\octave\packages\mapping-1.2.1
      miscellaneous  |   1.2.1 | ...\share\octave\packages\miscellaneous-1.2.1
                nan  |   3.1.2 | ...\OCTAVE~1.1\share\octave\packages\nan-3.1.2
             netcdf  |  1.0.11 | ...\share\octave\packages\netcdf-1.0.11
              nurbs  |  1.3.13 | ...\share\octave\packages\nurbs-1.3.13
                ocs  |   0.1.5 | ...\OCTAVE~1.1\share\octave\packages\ocs-0.1.5
             odepkg  |   0.8.5 | ...\share\octave\packages\odepkg-0.8.5
              optim  |   1.5.2 | ...\share\octave\packages\optim-1.5.2
         quaternion  |   2.4.0 | ...\share\octave\packages\quaternion-2.4.0
           queueing  |   1.2.5 | ...\share\octave\packages\queueing-1.2.5
             signal  |   1.3.2 | ...\share\octave\packages\signal-1.3.2
            sockets  |   1.2.0 | ...\share\octave\packages\sockets-1.2.0
          sparsersb  |   1.0.5 | ...\share\octave\packages\sparsersb-1.0.5
            specfun  |   1.1.0 | ...\share\octave\packages\specfun-1.1.0
            splines  |   1.3.2 | ...\share\octave\packages\splines-1.3.2
         statistics  |   1.3.0 | ...\share\octave\packages\statistics-1.3.0
                stk  |   2.4.2 | ...\OCTAVE~1.1\share\octave\packages\stk-2.4.2
            strings  |   1.2.0 | ...\share\octave\packages\strings-1.2.0
             struct  |  1.0.14 | ...\share\octave\packages\struct-1.0.14
           symbolic  |   2.6.0 | ...\share\octave\packages\symbolic-2.6.0
             tisean  |   0.2.3 | ...\share\octave\packages\tisean-0.2.3
                tsa  |   4.4.5 | ...\OCTAVE~1.1\share\octave\packages\tsa-4.4.5
              video  |   1.2.4 | ...\share\octave\packages\video-1.2.4
            windows  |   1.2.4 | ...\share\octave\packages\windows-1.2.4
             zeromq  |   1.2.1 | ...\share\octave\packages\zeromq-1.2.1

manually change paths in signal section of octave_packages to:

# name: dir
# type: sq_string
# elements: 1
# length: 55
%OCT_HOME%share\octave\packages\signal-1.3.2


# name: archprefix
# type: sq_string
# elements: 1
# length: 53
%OCT_HOME%lib\octave\packages\signal-1.3.2

and get:

>> pkg list
no packages installed.

change it back to "C:\Octave\Octave~1.1..." and 'pkg list' returns to normal.

so something about that syntax prevents pkg from parsing the entire file.  (also tested by changing the path to signal and going a 'pkg load control' and 'pkg load video', each listed before and after signal in the file, respectively. pkg returned a 'package control not installed' until I removed the %OCT_HOME% from signal.)

~dp0 is used by the .bat file, which gets the real path before it is ever passed to octave, so currently octave doesn't know what ~dp0 is.

As per this StackOverflow post: https://stackoverflow.com/q/45399494/4183191

The need to run pkg rebuild (plus pkg update) in order for the preinstalled packages to become accessible in the zipped version, while documented somewhere on the wiki, it is highly unlikely that a new user would know this in advance, and is likely to be a source of frustration and "first papercut" to the very first experience of installing octave on windows in that way.

While there are probably good technical reasons to not provide a generic octave_packages file in the portable version (presumably the paths need to be hardcoded and absolute), this information would probably need to be documented in the README file, and / or in the information window that comes up at first launch, informing the new user of this problem, and / or redirecting to the wiki for further instructions at the very least.