bugGNU Octave - Bugs: bug #59821, "pkg update" on windows...

 
 

bug #59821: "pkg update" on windows unexpectedly installs packages to local

Submitter:  Nicholas Jankowski <nrjank>
Submitted:  Mon 04 Jan 2021 06:26:08 PM UTC
 
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  Fixed Assigned to:  None
Originator Name:  Nicholas Jankowski Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Tue 19 Apr 2022 10:35:13 PM UTC, comment #37: 

No responses.  Assuming patch worked as expected.  Marking as Fixed and closing report.

Rik <rik5>
Project Administrator
Wed 01 Dec 2021 08:51:40 PM UTC, comment #36: 

I made some additional changes and pushed to stable here:
https://hg.savannah.gnu.org/hgweb/octave/rev/0fee9e910d84

We are duplicating some information from packages.txi in the docstring of pkg which is not ideal. But I guess this is slightly better than what we had before...

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Wed 01 Dec 2021 07:37:35 PM UTC, comment #35: 

revisiting the pkg bugs from earlier in the year - this bug is now just a doc update to clarify pkg install behavior.  the last patch still applies cleanly.

is the language acceptable and ok to push ahead of v7?

Nicholas Jankowski <nrjank>
Project Member
Wed 12 May 2021 12:50:53 PM UTC, comment #34: 

note that patch submitted for pkg update options handling at bug #60574 does make some doc changes that would require modification depending on if / when either is applied, and to stable or default.

Nicholas Jankowski <nrjank>
Project Member
Tue 11 May 2021 05:28:54 PM UTC, comment #33: 

added a v3 patch that has the revised text from comment #31.

(file #51420)

Nicholas Jankowski <nrjank>
Project Member
Mon 10 May 2021 06:02:03 PM UTC, comment #32: 

i created a separate bug report about pkg update ignoring -global/-local here:  bug #60574

I also just noticed bug #56128 requesting that update should respect -nodeps.  seems that there's just a general inability for update to handle options.

Nicholas Jankowski <nrjank>
Project Member
Mon 10 May 2021 02:55:48 AM UTC, comment #31: 

ok, about the consistency of the 'administrative rights' text.  Looking around, it seems 'administrative privileges' is a more generally used term to cover all OS's.  How about changing text at the front to the following:

## 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, which is usually only available when Octave is run with
## administrator privileges, such as when run as root (or superuser) on
## Unix-like systems, or run with elevated privileges ("Run as administrator")
## on Windows.
##
## In contrast, local packages are installed by default in the user's
## home directory (or user profile on Windows) and are only available to that
## specific user.  Usually, they can be installed without administrative
## privileges.

## Every time @code{pkg} is run Octave checks to see whether or not it has
## administrator privileges and sets the default install location to the
## global or local location accordingly.  Options when running @code{pkg} can
## changed this location as described below.
##

...

## @item -local
## A local installation (package available only to current user) is forced,
## even if Octave is being run with administrative privileges.
##
## @item -global
## A global installation (package available to all users) is forced, even if
## Octave is not being run with administrative privileges.

Nicholas Jankowski <nrjank>
Project Member
Mon 10 May 2021 01:50:53 AM UTC, comment #30: 

ok, last part first - pkg update ignores the -global/local flag. So in the current state that part of the revised help text is correct.

Just double checked this since some other bugs were fixed.  the global_install variable is not persistent.  so if you call 'pkg update -global', it will set global_install = true while it parses the update list, but then it calls 'pkg install -forge <pkgname>' for each item on the list.  it does not pass -global/-local, so when stepping through each install it reruns the superuser check each time, and sets it accordingly.  it would need some way of passing the global/local option to each pkg install call for it to carry through. 

it didn't look like too hard a fix, so I was planning on making a 'pkg updaet ignores -local/global option' bug report and playing with ways for it to pass that option, and then adjusting the docstring accordingly just hadn't gotten there yet.

Nicholas Jankowski <nrjank>
Project Member
Fri 07 May 2021 10:47:27 AM UTC, comment #29: 

That might be an issue because I'm no native speaker.
But I'd understand the section you cited differently:

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, which is usually only available when Octave is run with
administrative rights.  That means to install packages globally Octave checks if
it is executing as root (superuser) on Unix-like systems, or it is running
with elevated privileges ("Run as administrator") on Windows.

This section doesn't mention that this only affects the default value for global/local (i.e. if the respective switches are not passed explicitly).
It also suggests that this test is always performed for a global package installation.
The section doesn't sound to me like it contains a definition of "administrative rights" for the remainder of the text.

@@ -151,8 +155,9 @@
 ##
 ## @item update
 ## Check installed Octave Forge packages against repository and update any
-## outdated items.  This requires an internet connection and the cURL library.
-## Usage:
+## outdated items.  Updated packages are installed either globally or locally
+## depending on whether elevated privileges are detected.  This requires an
+## internet connection and the cURL library.  Usage:
 ##
 ## @example
 ## pkg update

"elevated privileges" is used without defining what that would mean, e.g. on Linux.
The added sentence also suggests that the installation destination depends on that condition only. Is that really the case? IIUC, passing "-global" or "-local" is still possible with that option.

Markus Mützel <mmuetzel>
Project Member
Thu 06 May 2021 04:20:45 PM UTC, comment #28: 

yes, the code checks the user's role at the start and sets 'global_install' accordingly.  the -global/local switch forces global_install to true or false regardless of the check.  it will try to perform installs accordingly whether access actually exists or not, with a permissions error if it tries to write where it cannot. The only text changed for the global/local options is the naming of the superuser role, leading to you other point:

I thought the second patch made this clarification as you suggested in comment #25:
Maybe you use something similar to this:

> Which package store is used by default depends on whether Octave is running with admin rights.  On Unix-like system, that means that Octave is executing as root (superuser).  On Windows, that means that it is running with elevated privileges (i.e., with administrator rights).


with the following revised text:

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, which is usually only available when Octave is run with
administrative rights.  That means to install packages globally Octave checks if
it is executing as root (superuser) on Unix-like systems, or it is running
with elevated privileges ("Run as administrator") on Windows.

it attempts to use administrative rights in a general sense for the rest of the help after defining what that means on linux and windows.

Did i misinterpret?

Nicholas Jankowski <nrjank>
Project Member
Thu 06 May 2021 12:52:42 PM UTC, comment #27: 

There are still issues with the wording afaict.
On Linux, there is no administrator (or administrative rights) afaict. The Linux user account that corresponds to the administrator on Windows is called "root" or "super user".
If you want to use it in that way, you have to write at least once what you mean by "administrative rights" or "elevated privileges" on each platform.

Also, afaict only the default (local or global installation) is determined by root/administrator. Does the code really check (unconditionally) if Octave is running as root/administrator if a user installs a package with "-global" and fail if it doesn't?

Markus Mützel <mmuetzel>
Project Member
Thu 22 Apr 2021 07:45:26 PM UTC, comment #26: 

I'd have to find it but I believe there was old language either in the doc or docstring that mentioned  dependence on 'write access' that is no longer there, and wasn't accurate. In any case, the criteria is user level, and that criteria is now applied uniformly across the different operating systems. I think as long as it's clear how octave makes the determination, it's not needed to call out write access (other than maybe that if -global is forced, octave will try to update them whether or not you actually have access to do so.) 

The package dependency order issue is reported in bug #47405

I think that wording looks okay, updated doc patch attached that I think captures most things pointed out in the recent comments.

(file #51306)

Nicholas Jankowski <nrjank>
Project Member
Thu 22 Apr 2021 05:33:04 PM UTC, comment #25: 

IIRC, the criterium of whether an installation will by default be global or local is not whether there is write-access to the global store. Instead, the criterium is whether Octave runs as root (superuser) on Linux or with elevated privileges (i.e. administrator rights) on Windows.
Maybe that could be clearer in the documentation.

I'm not sure if there is convenient wording that could be used cross-platform for this.
Maybe you use something similar to this:

> Which package store is used by default depends on whether Octave is running with admin rights.  On Unix-like system, that means that Octave is executing as root (superuser).  On Windows, that means that it is running with elevated privileges (i.e., with administrator rights).


After that, you could maybe just write "admin rights" to mean either of them.

Maybe, a native speaker could improve on that wording.

Also the point about package updates not getting (newly added) dependencies first is news to me. Did you verify that this doesn't work?
Is there a bug report about that? Instead of documenting it, we should probably better fix it if that doesn't work.

Markus Mützel <mmuetzel>
Project Member
Thu 22 Apr 2021 03:50:40 PM UTC, comment #24: 

'If Octave is running with' would be fine.  I just realized the change is about Octave running its own user-access-level check.  The main ida was to differentiate from whether or not the user actually has write access to the global packages. On windows at least, it's not uncommon for a user-level Octave instance to still be able to write to / install/update the global packages, especially since the zip/7z installer packages enable installation entirely in user-space.

I'm obviously used to speaking from Windows-centric location. happy to use non-platform specific wording where appropriate.

Nicholas Jankowski <nrjank>
Project Member
Thu 15 Apr 2021 09:22:59 AM UTC, comment #23: 

Should have been: "If Octave is running without elevated privileges"

Markus Mützel <mmuetzel>
Project Member
Thu 15 Apr 2021 09:21:39 AM UTC, comment #22: 

Do we expect this check to fail? If we don't, why don't write "If Octave is running with elevated privileges"? (Same point about platform specific wording still applies.)

Markus Mützel <mmuetzel>
Project Member
Thu 15 Apr 2021 09:15:50 AM UTC, comment #21: 

I think @nrjank refers to this "feature" of pkg:

https://hg.savannah.gnu.org/hgweb/octave/file/0ff064f09927/scripts/pkg/pkg.m#l393

Depending if this code "detects" elevated privileges, "-global" becomes default.

Kai Torben Ohlhus <siko1056>
Project Member
Thu 15 Apr 2021 08:42:50 AM UTC, comment #20: 

@nrjank re the patch in comment #15:
"Elevated privileges" is something Windows specific afaict. The manual should be platform agnostic at best or use wording for all platforms.

> If Octave does not detect that it is running with
> +## elevated privleges

Why "detect"?

Markus Mützel <mmuetzel>
Project Member
Thu 15 Apr 2021 05:07:00 AM UTC, comment #19: 

Title updated, I haven't tested extensively yet, if Linux was affected, too.

Off-topic:
In the end, "my" pkg will be a package, synchronized with the current Octave development sources.  Using this approach changes become backward compatible down to older Octave 4.x versions and more decoupled of a certain package index like Octave Forge or Octave Packages.

For more ideas and discussion what I am working on, here is a slept in discussion https://octave.discourse.group/t/online-developer-meeting-2020-11-10-the-future-of-octave-packages/349

Kai Torben Ohlhus <siko1056>
Project Member
Thu 15 Apr 2021 02:51:38 AM UTC, comment #18: 

Ooh, sloppy on the typos sorry.  Need a notepad++ spellcheck.

The originating issue was more that pkg update (actually pkg install) now actually obeyed the same global/local default check on Windows as Linux, and it was an unexpected change on windows. Looking at comment #6 changeset it seems windows previously just defaulted always to global, and that FIXME was finally fixed :).

How about just "pkg update on windows unexpectedly installs packages to local?" not terribly important since I think this bug got more life than it really warranted anyway.

Is the hope to get your pkg work in for v7? I was thinking the options for pkg update might be a quick patch on the hg repo, but don't want to split the effort.

Nicholas Jankowski <nrjank>
Project Member
Thu 15 Apr 2021 01:36:44 AM UTC, comment #17: 

@nrjank: does the new title catch the essence of the problem?

Recently, I came back to work more on pkg again

https://github.com/gnu-octave/pkg

and am interested in the open package bugs

https://octave.space/savannah/?Action=get&OpenClosed=open&Format=HTMLCSS&Title=pkg&Category!=Forge

There I try to better document/understand the decisions made for the package eco-system.

Thanks for your patch (file #51266), I incorporate your thoughts into my work.  Just to note, there are small typos, e.g. "packgaes", and I prefer "https://octave.org" as official Octave website.

Kai Torben Ohlhus <siko1056>
Project Member
Wed 14 Apr 2021 06:13:11 PM UTC, comment #16: 

in retrospect this bug probably should also have had name/category changes since it all has to do with pkg and nothing to do with octave forge or the packages themselves.

Nicholas Jankowski <nrjank>
Project Member
Wed 14 Apr 2021 06:03:44 PM UTC, comment #15: 

circling back to this, I haven't been able to recreate the odd issues with things updating/installing that I mentioned in comment #8.  dismissing it as the result of me playing with too many things at once. What remains is mainly a documentation update:

- i think the Octave for Microsoft Windows wiki is sufficiently updated to account for the v6 pkg behavior.

- i see the latest version of /doc/interpreter/package.txi on default has already been updated from the currently published 6.2.0 help to include windows behavior (looks like @mmuetzel did that through http://hg.savannah.gnu.org/hgweb/octave/rev/280defaf2023 )

- I went through the pkg docstring and made a few clarifications to the section at the front on global/local location, and added a couple notes under the 'pkg update' section.  While I was at it I also added a note about pkg update order and dependencies, which had been noticed back in bug #47405. That and couple minor changes to package.txi are in the attached patch.

As is, other than trying to remember to include changes like this in the Release News moving forward, I think that covers all of the concerns brought up in this bug report.

I may file a wishlist report for pkg update to recognize -local and -global options, and maybe -list as well for a 'available updates' report, but that can be separate from this.

(file #51266)

Nicholas Jankowski <nrjank>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51420:  pkg_doc_update_v3.diff added by nrjank (6KiB - application/octet-stream)
file #51306:  pkg_doc_update_v2.diff added by nrjank (6KiB - application/octet-stream - clean up and updated cross platform language)
file #51266:  pkg_doc_update.diff added by nrjank (4KiB - application/octet-stream - documentation updates regarding pkg global/local/update behavior)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-04-19 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-12-01 mmuetzel StatusNeed Info Ready For Test
        Operating SystemMicrosoft Windows Any
    2021-12-01 nrjank CategoryOctave Function Documentation
        Item GroupUnexpected Error or Warning Documentation
    2021-05-11 nrjank Attached File- Added pkg_doc_update_v3.diff, #51420
    2021-04-22 nrjank Attached File- Added pkg_doc_update_v2.diff, #51306
    2021-04-15 siko1056 Operating SystemAny Microsoft Windows
        Summary"pkg update" ignores previous package version to be global or local "pkg update" on windows unexpectedly installs packages to local
    2021-04-15 siko1056 CategoryOctave Forge Package Octave Function
        StatusNone Need Info
        Release6.1.0 dev
        Operating SystemMicrosoft Windows Any
        Summary[octave forge] (ga) pkg update with ga 0.10.2 installs in user home folder instead of packages folder on windows "pkg update" ignores previous package version to be global or local
    2021-04-14 nrjank Attached File- Added pkg_doc_update.diff, #51266
    2021-01-04 nrjank Carbon-Copy- Added lostbard

    Back to the top


    Powered by Savane 3.9