bugGNU Octave - Bugs: bug #59821, [octave forge] (ga) pkg update...

 
 

bug #59821: [octave forge] (ga) pkg update with ga 0.10.2 installs in user home folder instead of packages folder on windows

Submitted by:  Nicholas Jankowski <nrjank>
Submitted on:  Mon 04 Jan 2021 06:26:08 PM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  None Assigned to:  None
Originator Name:  Nicholas Jankowski Open/Closed:  Open
Release:  6.1.0 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 05 Jan 2021 05:15:35 PM UTC, comment #14: 

sorry for the comment flood

in reverse order-
unless I'm reading the code wrong I don't see how pkg update can be affected by -global. for each pkg to update it calls

pkg install -forge <pkgname>

and the package name is just its short-name (audio, etc.) so the global flag is ignored.  I'll need to remove that suggestion from the wiki. it doesn't look possible to pass any options to update

stepping through the package update info collection, things just look stranger yet.  my pkg local_list is C:\Users\NICHOL~1.JAN\.octave_packages

and the initial pkg update updated the two global packages with local updates in C:\Users\NICHOL~1.JAN\octave

but after the series of pkg updates, etc. mentioned below the two packages in the local_packages list have locations set to, e.g.,

C:\Programs\Octave\octave-6.1.0-w64\mingw64\share\octave\packages\nan-3.5.2

so, somehow both my local and global lists are pointing to the same global packages?  I didn't make any manual prefix changes or anything I can see explaining this. And I'm always just running as a user.  I think I might just delete and re-extract the archive and see if I can reproduce any of this.

regarding the other points:  previously, at least the zip archive windows versions always made changes to global packages using default configuration, I don't know about the exe installer and whether its behavior depended on root privileges or install location. but some of the help text makes reference to needing write access to do global installs, but the automatic check is really for user-admin level, not write access. so maybe some doc clarification needed there since those aren't interchangeable.

last, will re-tweak/correct the wiki.

Nicholas Jankowski <nrjank>
Tue 05 Jan 2021 10:57:17 AM UTC, comment #13: 

Re comment #10 "without changing core Octave behavior": Functions in packages might shadow functions in core Octave. So packages potentially change core Octave behavior (and afaict some do).

Re comment #11: IIRC, behavior on Linux is that packages are installed globally by default if Octave runs with root privileges. They are installed locally by default if Octave runs without root privileges. Similarly on Windows, packages install globally by default if Octave runs with elevated privileges ("Run as administrator"). They are installed locally by default otherwise.

Re comment #9: Local package installations always shadow global package installations (independent on version or installation order).

Re comment #12: I didn't look at the code. But I assume `-global` can be used as a parameter for `pkg update`, too.

Markus Mützel <mmuetzel>
Project Member
Tue 05 Jan 2021 04:43:05 AM UTC, comment #12: 

2nd - trying to understand how my 'pkg update -global' command from comment #9 worked. global_install is not set as global or persistent (if I understand persistent right within context of recursive functions).  but after 'pkg update' builds its list and calls each 'pkg install', it does not pass the '-global' option.  it just calls

feval (@pkg, "install", "-forge", installed_pkg_name);

so now I'm not quite sure why running 'pkg update -global' worked to update the global packages the last time, when it did a local update the first time. The only automatic check for global_install is the _is_elevated_process_ check.

what am i missing?

Nicholas Jankowski <nrjank>
Tue 05 Jan 2021 04:23:29 AM UTC, comment #11: 

looking at verbiage in the pkg help text, is it correct to say that 'pkg install -local' is the current default behavior? Or does that option imply something that isn't true by default?   The help text says that '-local' forces local install even if you have admin/root privileges.  That indirectly implies that if you did have system priv, it wouldn't normally do a local install.  On windows, that doesn't seem to matter now, as it does a local install by default whether or not you have write access to the Octave installation folder.

Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 10:30:37 PM UTC, comment #10: 

made updates to
https://wiki.octave.org/Octave_for_Microsoft_Windows

will scan through pkg help later

Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 09:34:00 PM UTC, comment #9: 

(confirming that after closing octave, deleting the local pkg folder, rerunning 'pkg update -global', pkg list now shows updated packages in the global location.

probably should rename the bug.  if there's no actual installation bug (2) in comment #8, then it's just a documentation issue. i'll start looking through updates for doc and the wiki.

Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 09:32:57 PM UTC, comment #8: 

yes, this is the first I recall seeing it. Saw some comments on pkg in News but didn't see anything about changing that aspect of pkg behavior. 

Just to clarify, if we're now going to have cross-platform consistent   package handling-

(1) i didn't think the 'pkg update' command took other flags.  but -global seemed to do something.  do all of the 'install' options pass through to 'update' as well? if so that would be a useful and easy doc note to add. 

(2) can you explain why I still have a local ga&nan, an older global ga&nan, and after 'pkg update -global' and 'pkg rebuild' I'm now seeing just the old versions in pk list, showing the global location? did something about that command tell octave to ignore the presence of things in local? and if so why didn't it actually update the global packages? may be some kindof bug hiding in there.

(3) If I still want to operate with packages being isolated to the installs like they were pre-v6, should 'pkg update -global' work or should 'pkg update' just be avoided altogether?

Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 09:11:36 PM UTC, comment #7: 

That change was intentional to have consistent behavior cross-platform. Linux also updates packages to the local package store unless it is run as root.

From the documentation of `pkg`:

> Packages can be installed globally (i.e., for all users of the system) or locally (i.e., for the current user only).
> Global packages are installed by default in a system-wide location. This is usually a subdirectory of the folder where Octave itself is installed. Therefore, Octave needs write access to this folder to install global packages. That usually means that Octave has to run with root access (or "Run as administrator" on Windows) to be able to install packages globally.
> In contrast, local packages are installed by default in the user’s home directory (profile on Windows) and are only available to that specific user. Usually, they can be installed without root access (or administrative privileges).
> For global and local packages, there are separate databases holding the information about the installed packages. If some package is installed globally as well as locally, the local installation takes precedence over ("shadows") the global one. Which package installation (global or local) is used can also be manipulated by using prefixes and/or using the ‘local_list’ input argument. Using these mechanisms, several different releases of one and the same package can be installed side by side as well (but cannot be loaded simultaneously).


Improvements to the documentation are always welcome.

Markus Mützel <mmuetzel>
Project Member
Mon 04 Jan 2021 07:38:49 PM UTC, comment #6: 
John Donoghue <lostbard>
Project Member
Mon 04 Jan 2021 07:36:25 PM UTC, comment #5: 
John Donoghue <lostbard>
Project Member
Mon 04 Jan 2021 07:27:45 PM UTC, comment #4: 

yes, I have write access to both. this is different than behavior in Octave 5.2, where the windows install always put packages in the global installation.  A pkg update always updated the packages in the same place they were located.

I seem to recall some discussion about pkg changes, but can't seem to locate them. I thought they focused on having pkg respect %OCTAVE_HOME%? don't recall any intentional discussion of changes to install behavior, and don't see anything in the news.  Windows specific change?

As I keep multiple versions of Octave installed using the zip archives, and each has its own package set, this will complicate things a bit.  If this is new expected behavior I guess I'll have to get used to specifying global installs. does 'pkg update -global' work?

  • I just tried a pkg update -global, and pkg list was unchanged. then did a pkg rebuild, and pkg list is showing the original global packages, despite the other pkgs still being located in that home folder.  this is odd.
Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 06:52:17 PM UTC, comment #3: 

Do you have write permissions to the original installed/octave paths?

Not sure if its a bug or just  should be clearer on documentation? As it does update the package the user has access to. It just doesnt remove the global one.

Its probably the same in linux ?

John Donoghue <lostbard>
Project Member
Mon 04 Jan 2021 06:31:26 PM UTC, comment #2: 

sorry, it updated nan and also put it in the same %USER%/octave/ folder instead of the packages folder under the installation.

Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 06:30:30 PM UTC, comment #1: 

i just noticed it also updated nan from 3.5.0 -> 3.5.2, so this appears to not be specific to the ga package, and is probably more specific to the windows build.

note i'm running a version from the zip package, not the exe installer.

Nicholas Jankowski <nrjank>
Mon 04 Jan 2021 06:26:08 PM UTC, original submission:  

Octave 6.1.0 on Windows comes with ga 0.10.1 located in:

\octave-6.1.0-w64\mingw64\share\octave\packages

running a pkg update attempts to upgrade to ga 0.10.2.  doing so produced the following warning:

warning: creating installation directory C:\Users\NICHOL~1.JAN\octave
warning: called from
    install at line 36 column 5
    pkg at line 568 column 9
    pkg at line 727 column 11

For information about changes from previous versions of the ga package, run 'news ga'.

pkg list now shows :

 ga  |  0.10.2 | C:\Users\nicholas.jankowski\octave\ga-0.10.2

looking around, sure enough the installation is sitting by itself in a new \octave\ folder.  looking at C:\Octave\octave-6.1.0-w64\mingw64\share\octave\packages,  I see ga-0.10.1 is still there.

a subsequent pkg install -forge ga just overwrites the one in my home folder.

Nicholas Jankowski <nrjank>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by nrjank (Submitted the item)
  • -email is unavailable- added by nrjank (pkg maintainer)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-04 nrjank Carbon-Copy- => Added lostbard

    Back to the top


    Powered by Savane 3.5