bugGNU Octave - Bugs: bug #47405, pkg update errors out of one...

 
 

bug #47405: pkg update errors out of one package sees dependency error

Submitted by:  Nicholas Jankowski <nrjank>
Submitted on:  Mon 14 Mar 2016 03:22:21 AM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Confirmed Assigned to:  None
Originator Name:  Nicholas Jankowski Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Mon 04 Apr 2016 01:57:47 PM UTC, comment #5: 

Recording some thoughts here for a workable hack vs a better fix:

most of pkg.m is a top level wrapper with work in the private functions. In particular, pkg update calls install.m for each package after generating a list to iterate through. install.m has 'unsatisfied dependency' as an error, so this aborts the whole update process. install.m is called without any expected return variables, so there's no feedback to pkg.m, and dependencies aren't checked by pkg.m, just inside install.m

1 - bare minimum fix: "don't abort the pkg.m update sequence when a dependency error is encountered."
--> is there a way for the error (or something similar) to only abort the current script and return control to the calling function pkg? Would there be a problem if this was replaced with a warning?  for a single pkg install, I believe either a warning or an error would be the last thing done by the script. for multiple installs, a warning would inform the user but still continue to try the other packages.

2 - #1 + inform the user in some way that they should re-run pkg update - if changed to a warning, there should be a way to check if a particular warning  was issued, change a flag to 'dependency_error_encountered', and then at the end of the update process, produce a 'you should re-run pkg update' message.

3 - if #2 is happening, other things could be triggered by the flag, such as logging the package(s) that caused the error, and retrying them once at the end of the update script.

4 - the most desirable option, that pkg checks for dependencies and re-orders the update list so that nothing occurs out of order, would require moving (copying) the dependency check from install to pkg. Not too difficult, but much more involved.

Nicholas Jankowski <nrjank>
Tue 15 Mar 2016 08:21:19 PM UTC, comment #4: 

I don't know about the bigger pkg environment challenge, but I'll take a look at this specific bug. If I can wrap my head around what pkg is doing I'll see if any hacks (in the order specified in my first comment) are workable. Once we have this tackled, I'll start peeking at some of the other pkg project issues, and see if any sit within my current comfort zone. ;)

Nicholas Jankowski <nrjank>
Tue 15 Mar 2016 07:49:39 PM UTC, comment #3: 

Oh, if you (or someone else) would pick this up that would be great :-)

This dependency issue has always been a stumbling block for novice users;  I didn't realize  it could also a stumbling block for all of us when upgrading all packages. As I upgrade Octave (on Windows) about twice a week and OF packages are automatically renewed in that process I never noted pkg.m's "upgrade" instruction.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 15 Mar 2016 04:57:48 PM UTC, comment #2: 

yes, I realized there has been quite a bit of discussion on modifications to the package handling.  I called this one out here mainly because it seems to be a specific bug with a possible shorter term fix (or hack) that it errors out and fails to continue updating other packages.

what you say sounds ideal. I didn't realize it was sitting in m-code. I may take a peek.

Nicholas Jankowski <nrjank>
Tue 15 Mar 2016 04:50:27 PM UTC, comment #1: 

(bug report title could use some polishing :-) )

I'm afraid that for some packages several iterations are needed instead of just two (e.g., communications depends on signal that depends on control).
It is probably better if pkg.m would set up a dependency tree, descend into it and infer an optimal "route" for each OF package to upgrade it, rather than cycle through all OF packages again and again.
Actually, a case can be made that it should do so when installing packages as well, esp. with the -forge flag.

In fact similar ideas have been mentioned as a Project Idea here:
http://wiki.octave.org/Projects#Packaging

I think it probably isn't very hard to set up dependency trees for OF packages; parsing & interpreting the share/octave/octave-packages file would be a first start and much of that code is present in pkg.m and its companion functions.
Making pkg.m follow the optimized "route" through the package collection is probably the hardest part. But again, maybe not.

But admittedly pkg.m is quite a beast; I've tried improving it before (as regards what to do about shadowing core functions ad matching functions from other OF packages) and I quickly lost track :-(

(release => dev; OS => any)

Philip Nienhuis <philipnienhuis>
Project Member
Mon 14 Mar 2016 03:22:21 AM UTC, original submission:  

When running 'pkg update' it appears to work through the packages in some particular order (alphabetical order, or install order) When one of the packages has a dependency on a version of a package that has not been updated yet, pkg errors out back to the command line and does not continue checking any other packages for updates.

This can be seen in the windows version of 4.0.0 where the default package set is a bit out of date. Running the build_packages script followed by pkg update gives the following error:

error: the following dependencies were unsatisfied:
> >    optim needs struct >= 1.0.12

And pkg update cannot proceed to other packages until struct is done first. While this is not difficult to do, it may be confusing for a new user.

I would think the simplest solution would be for package to somehow catch the error and step over that package. Then running the update twice would result in everything being fully updated. Perhaps if it needed to step over a package it could tell the user he should probably rerun the update.

Alternatively it would be nice if it would just recognize that it had to step over one of the packages and to try it again at the end. If it failed again and could tell the user.

Really nice would be for it to recognize which package is needed, if it is already installed run that update first, if it's not installed ask the user whether it should be installed, and then after the dependency has been satisfied pick up the update process where it left off.

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 mtmiller (Updated the item)
  • -email is unavailable- added by nrjank (Submitted the item)
  •  

    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.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-31 mtmiller CategoryNone => Octave Function
        StatusNone => Confirmed
    2016-03-15 philipnienhuis Release4.0.0 => dev
        Operating SystemMicrosoft Windows => Any

    Back to the top


    Powered by Savane 3.5