bugGNU Octave - Bugs: bug #53984, pkg update - Unable to continue...


bug #53984: pkg update - Unable to continue updating when a package error is found

Submitted by:  Renato <yamane>
Submitted on:  Sat 26 May 2018 10:30:10 AM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.4.0 Operating System:  Any

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)

Thu 31 May 2018 03:34:55 PM UTC, comment #11:

In repply to Comment #7, using the solution on Comment #8:

- Newer A depends on newer B
- Newer B depends on newer A

If Package A have a BUG, the array commented on Comment #8 will be:

Package A will fail to install, so it will receive a flag "blacklist" on the array;
By consequence, Package B also will receive a flag "blacklist"

If Package B have a BUG, the array commented on Comment #8 will be:

Package A will be installed;
Package B will fail to install, so it will recieve a flag "blacklist".
By consequence, the array will update also the flag of Package A, adding it in the blacklisted.

In the end, Package A and Package B will be blacklisted.

Renato <yamane>
Wed 30 May 2018 08:33:57 PM UTC, comment #10:

BTW none of your solutions properly handles mutually dependent packages (see my comment #7).
Maybe the '-nodeps' option could help there.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 30 May 2018 08:30:33 PM UTC, comment #9:

Well, you're determined :-) (good!)

pkg.m is an .m file function so it should be easy to adapt it.
Look at L.575 and up.
A try-catch around L.597 could be a first start.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 30 May 2018 07:39:54 PM UTC, comment #8:

1) Run the pkg update;

2) Make an array with all dependencies;

3) Make a "simulated installation" in alphabetical order;
3.1) If an error is found, update the array adding a blacklist flag on dependencies;
3.2) Also mark this broke package as blacklisted;

4) When finish the loop on step 3.x, we will have an array with all packages blacklisted.

5) Now, run the definitive installation, skipping all packages blacklisted.

This will take too much time, so, just skip the broke package and update the next one.

"pkg update" must make it´s job, that is: UPDATE!
If a package is broke, the package maintainer must fix it, instead the "pkg update" deny update the next packages.

Renato <yamane>
Wed 30 May 2018 06:47:54 PM UTC, comment #7:

As to your 2nd option:
All packages that have dependencies (other packages or external libraries) DO have their dependencies mentioned in their DESCRIPTION file.

So with that out of the way, how would you suggest to handle mutual dependencies where newer A depends on newer B and newer B depends on newer A? Your suggested options would result in skipping both.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 30 May 2018 06:27:07 AM UTC, comment #6:

IMHO, it must be fixed as I told on the first comment.
- If a problem is found, skip it and update the next package.

Or, if you like a more robust system, all packages must have a flag "dependency". So, each maintainer must add all dependencies to be processed by "pkg update" on the beginning of the update.

Renato <yamane>
Tue 29 May 2018 08:49:34 PM UTC, comment #5:

So what is your conclusion? How do you think 'pkg update" can / should be fixed?

Philip Nienhuis <philipnienhuis>
Project Member
Tue 29 May 2018 07:06:59 PM UTC, comment #4:

What you would like to avoid is possible to happen even today.

Lets see:

You have 2 packages installed:
- Package "A", version 3.0
- Package "B", version 4.0

Both have an update available:
- Package "A", version 3.5 and is dependent to Package "B" v4.5;
- Package "B", version 4.5 have a bug and will fail to update.

As the update is by alphabetical order, this will happen:

- Package "A" will be updated;
- Package "B" will fail.

So, the Package "A" will not work, because is missing the latest version of Package "B".

Best regards,

Renato <yamane>
Mon 28 May 2018 03:45:29 PM UTC, comment #3:

You seem to miss the point in your first example.
What if package B were dependent on package A v1.5?
If updating A to 1.5 failed, yet package B would succesfully be updated to 2.0 (dependent on A v1.5), package B would be left with an unfulfilled dependency.

You're quite right that updating in alphabetical order looks suboptimal at best. It seems better to update in order of dependency, but then again, what if two or more packages are mutually dependent?

IMNSHO the whole idea of having an option to update all packages with just one command is asking for trouble.
The culprit is not so much the package system itself but rather that:

  • packages may not have been fully tested for proper installation on as many systems as possible;
  • new packages may have new dependencies, not only other packages but maybe system and/or external libraries as well.

To make that all failsafe within one command is simply untenable.
It is much better practice to update packages one by one, taking dependency order into account and with the "-nodeps" flag where unavoidable.

So all in all the workflow for "pkg update" as it stands is IMO the right one:
"pkg update" stops at a failing package installation and IMO rightfully requires to first fix that installation failure (maybe manually with a simple "-nodeps" flag); and then, once fixed, try the next packages, hopefully w/o new errors.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 27 May 2018 08:14:11 PM UTC, comment #2:

If a package update fails for an specific package. It will kept in the same version (not updated).

Example of interdependence:
Package A, current version 1.0
Package B, current version 1.0

Package A have an update (and result in an error when try to update to version 1.5)
Package B have an update and can be updated to version 2.0 with no problem.

So, after an "pkg update", we must have:
- Package A: not updated, kept at version 1.0
- Package B: updated to version 2.0

Today, it works not updating NOTHING.
Even packages not interdependent (Package C, Package D, etc) will NOT be updated.

One more thing: today, the packages are updated by alphabetical order.
So, if you have two packages interdependent, one is Package "A" and other is Package "Z", and both packages have an update, but a problem happens on the Package "Z", we will have the Package "A" updated and Package "Z" not updated.

Renato <yamane>
Sun 27 May 2018 07:34:00 PM UTC, comment #1:

What if a package update fails, and the next package that does get updated is dependent on the failed package? Then two packages wouldn't work.

Package interdependencies, of which there are quite a few, make it less easy than you seem to think.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 26 May 2018 10:30:10 AM UTC, original submission:

When run "pkg update", if an error is found in a specific package (e.g. https://savannah.gnu.org/bugs/?53865) the update of the other packages is unable to continue.

Expected behavior: when an error is found, skip it and continue the update of the next package.

Renato <yamane>


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

Attach Files:

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 yamane (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.




    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-27 philipnienhuis Operating SystemMicrosoft Windows => Any

    Back to the top

    Powered by Savane 3.3