[Octave-bug-tracker] [bug #47405] pkg update errors out if one package sees a dependency error

[Philip Nienhuis]

Follow-up Comment #6, bug #47405 (project octave):

I forgot a bit about my work on pkg.m a while ago (about dependencies and
inverse dependencies, etc). At the time I did think about this, and from what
I remember it shouldn't be to hard to more or less do the update work safely
by *implicitly* following the dependency tree, w/o actually deriving it. In
comment #1 I really over-engineered it.
The private functions installed_packages.m and get_inverse_dependencies.m do
the required work. Here's what I was thinking:

Step 1:
'pkg update' could start with updating all packages that have no dependencies;
easily derived from the info in the 'installed_pkgs_list' struct created by
installed_packages.m. That'll take care of the ultimate "leafs" of the
dependency tree.
Most packages have no inverse dependencies so for those the story ends there;
they can be marked as 'done'.

Step 2:
Next, get_inverse_dependencies.m could find out which packages directly depend
on the ones that are already updated in step 1. Updating those should be a
safe action and would take care of a level higher up in the dependency tree.
The packages updated in step 1 that hadn't yet been marked as 'done' can now
be marked.

Steps 3 - ....
And so on, until all packages have been updated.

Of course there'll be gotchas but that's the fun part :-) For one, think of
circular or even entangled dependencies - but do we have those? they'd be a
pain when installing anew in the first place. For another, think of required
libraries.
Maybe circular deps. can be detected and processed separately for each step 2
and up using the '-nodeps' option, or maybe they can only be updated in the
end using '-nodeps', I'm unsure.

It all doesn't look hard to me, but I have no time now to set this up. Some
more thinking is required about finding out which packages can be updated
safely in the next round and what to do with all the corner cases & gotchas.
But all in all I'd be surprised if this were to lead to more that half a
screenful of code. Some while or do...until loop seems ideal for the job.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?47405>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/