Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

Hi, for quite some time folks have occasionally requested that dispel
understand dependencies. I've tried to combine the various requests
together in such a way that it provides a reasonable user
interface. Please let me know what you think, if you have any comments,
questions or suggestions, feel free.


Purpose:
Herein is a proposal for a specification of the integration of dependencies
and dispel. Dispel will be enhanced to travel up and down the dependency
tree.

Definitions:
dispel: to remove a spell from the system

dependency information is taken from /var/state/sorcery/depends (aka
$DEPENDS_STATUS). This is known as the on-disk dependency information
and presents our best knowledge of the relationships between spells as
they are currently installed.

Unless otherwise specified a 'dependency' can refer to either a mandatory
or optional (with a value of on) dependency. You can think of the
dependency tree itself as a directed graph, there is no immediate and
obvious distinction between depends and optional_depends.

Downward dependency: A spell that depends (directly) on another spell,
for example xorg depends on perl (stated in xorg's DEPENDS file), in
this case perl is a downward dependency from xorg. These may also be
referred to as children, perl is a child of xorg.

Upward dependency: The notion of a parent spell that depends on the
current spell. For example, xorg depends on perl, 'perl' is said to have
an upward depends, or parent named 'xorg'.

Orphan: A special case of a child, a spell which has no parent
dependencies. Orphans are created in the context of dispel when a spell
has exactly one parent and that parent is being dispelled.

Behavioral overview:

A user may elect to dispel some set of currently installed spells. Once those 
spells are dispelled, dispel may prompt the user about removing some portion 
of
the (former) children of the dispelled spells. The child spells that the user
elects to remove are then dispelled and the process repeats with the
children of the newly dispelled children (the grandchildren). This
process repeats until no spells are available or selected by the user.

Once this process is complete a second phase is initiated. In this phase
the parents of the newly dispelled children may be selected for repairs if
possible (recast without their optional dependent children), queued
for dispel, or ignored. Spells listed for recast are recast with their
dependency information modified to accommodate the removed child. Once
this is complete the process restarts at the previous paragraph with
the spells recently queued for dispel.

NOTE: That by dispelling any spell which is a non-orphan, it will break
the dependencies of its parent spells. If all the broken dependencies are
optional then the spell is repairable. If one or more of the dependencies
is non-optional repairing the spell is assumed to be impossible, and thus
the user may either choose to ignore the problem or continue dispelling
up the dependency tree.

NOTE: This dependency repairing has been in cleanse --prune for quite
some time, this process is not meant to supplant that functionality,
just to provide a convenient way to manage removing spells. More on
this later.

Dispelling down the dependency tree:

Given a set of spells, there is some set of children. A subset of those 
children
may become orphans when the current spells are removed. Subtracting the set 
of (soon to be) orphans from the set of all children results in the set of 
'non-orphan', or in other words, spells that have parents outside the current 
set of spells.

The code may elect one of four behaviors for either the set of orphans,
the set of non-orphans (or the same behavior for both).

Short name      Character       Description
always remove   A               Always dispel this class matter what
query-y         Y               Query about removal, default to 'yes'
query-n         N               Query about removal, default to 'no'
ignore          I               Ignore completely

A default policy will be selected through a menu interface (described below)
and the code will behave according to those policies. If necessary
querying the user and obeying their requests.

There will also be 12 new options as follows (replace X with 'a' 'y'
'n' and 'i'):

--orphan-X      Apply behavior X to newly discovered orphan spells
--non-orphan-X  Apply behavior X to non-orphan spells
--child-X       Apply behavior X to any child spell

The behavior and effect of each parameter is explained below, the
parameters on the left apply to only orphans, the ones of the right
apply to non-orphans and the parameters in the middle apply to both.

                        orphan                  non-orphan
--orphan-i              I       --child-i       I       --non-orphan-i
--orphan-n              N                       I       --non-orphan-i
--orphan-y              Y                       I       --non-orphan-i
--orphans-a             A                       I       --non-orphan-i
--orphans-i             I                       N       --non-orphan-n
--orphan-n              N       --child-n       N       --non-orphan-n
--orphan-y              Y                       N       --non-orphan-n
--orphan-a              A                       N       --non-orphan-n
--orphan-i              I                       Y       --non-orphan-y
--orphan-n              N                       Y       --non-orphan-y
--orphan-y              Y       --child-y       Y       --non-orphan-y
--orphan-a              A                       Y       --non-orphan-y
--orphan-i              I                       A       --non-orphan-a
--orphan-n              N                       A       --non-orphan-a
--orphan-y              Y                       A       --non-orphan-a
--orphan-a              A       --child-a       A       --non-orphan-a


--orphan and --non-orphan parameters may be used simultaneously, the
--child parameters are simple a shorthand for using both with the same
value. The last parameters specified take precedence over previously
specified ones.

The default behavior will be to ignore dependencies. This is to maintain
backwards compatibility with spells that use dispel.

There will be additional parameters to use user-defined values from a menu. 
Here is the downward depends half:

The option to enable this will be: '--user-child-deps' (or something better,
and probably a shorthand version). Here is the menu description:

User Dispel Deps Menu (Part 1) (X indicated default)

Menu 1: behavior for orphan 
radio buttons:
        [ ] always remove
        [ ] query-y
        [ ] query-n
        [X] ignore

Menu 2: Behavior for non-orphan 
radio buttons:
        [ ] always remove
        [ ] query-y
        [ ] query-n
        [X] ignore

Part 2 of the menu described below

Dispelling Up the dependency tree:

As mentioned above, when a spell is removed, it potentially breaks parent
spells, the only case where this doesn't happen is if the spell is a
(soon-to-be) orphan, in which case all of its parents are being removed.

The more interesting case is when a child has parents which are not being
removed. That upward dependency may be required or optional (and set to
on). Currently this process is mitigated by cleanse --prune. Cleanse
--prune will remain the definitive tool for repairing such dependency
holes. The work here is merely a convenience to supplement this issue. The
user is always given the option to 'opt-out' of any action for later.

If a parent loses only optional dependencies it can in theory be repaired
by recasting with all those optional dependencies set to off. The
dispel tool can cause cast to default to off values for these dependency
questions on a recast.

An alternative to broken parents is to dispel them, this is referred to as
dispelling up the depends tree. For example, you want to remove xorg and
anything that uses it, so you remove xorg, thus breaking all the window
managers and lots of other things that need X, at this point you dispel
all the window managers and x libraries, and then dispel anything left
that needs those X libraries, and on upward until you're left without
anything needing X.

Finally the user has the option of ignoring a particular parent with the
understanding that they will use cleanse --prune later and not complain
that something is broken (this is the current behavior already).

This behavior can be invoked by the use of a special command
line parameter, --user-up-deps (or something).

The user is presented with one of two menus, similar to cleanse --prune:
        (1) Ignore
        (2) Dispel
        (3) Recast
Or if the spell is unrepairable
        (1) Ignore
        (2) Dispel

There will be sorcery menus to select the default answers to both of
the above queries.
        
User Dispel Deps Menu (Part 2)

Menu 3: Recastable parents
radio buttons:
        [ ] recast
        [ ] dispel
        [X] ignore

Menu 4: Non-recastable parents
radio buttons:
        [ ] dispel
        [X] ignore


"Real Life" Examples:

Imagine the following dependency graph (notice its cyclic)
xorg -optional-> libpng
xorg -required-> ghostscript
ghostscript -required-> libpng
ghostscript -optional-> xorg

Hypothetical situation 1:
User runs "dispel xorg"
xorg is dispelled
libpng is a child remove it? (user selects no)
ghostscript is now an orphan remove it? (user selects no)
ghostscript has a broken dependency on xorg (user elects to dispel)
libpng is now an orphan remove it? (user selects yes)
End Result: All three removed

Hypothetical situation 2:
User runs "dispel xorg"
xorg is dispelled
libpng is a child remove it? (user selects yes)
ghostscript is now an orphan remove it? (user selects no)
ghostscript has a broken dependency on xorg and a broken dependency on libpng
        since libpng is a required dependency ghostscript is not fixable
        (user elects to dispel ghostscript)
End Result: All three removed

Hypothetical situation 3:
User runs "dispel xorg"
xorg is dispelled
libpng is a child remove it? (user selects no)
ghostscript is now an orphan remove it? (user selects no)
ghostscript has a broken dependency on xorg (user elects to recast)
End Result: ghostscript and libpng installed, xorg removed

Attachment: pgpAau9w0QbCU.pgp
Description: PGP signature