No subject

> Which is why we're adding signal handling to fix that.

I certainly wouldn't mind cherry-picking the patch once it's finished.

> It's an SQLite database, each transaction will trigger a change to the

And each transaction is similarly susceptible to corrupt the file when interrupted?

> using the database access layer (on standard OS X filesystems), so this
> achieves nothing: How would you ensure that the database isn't being
> modified while you copy it?

Use the registry.lock file?

> Josh's answer sounds like it's not that much effort. I don't know,
> however, I'm not very familiar with that part of MacPorts base.

Looking at macports::upgrade I see this:

{{{
    # stop upgrade from being called via mportexec as well
    set orig_nodeps yes
    if {![info exists macports::global_options(ports_nodeps)]} {
        set macports::global_options(ports_nodeps) yes
        set orig_nodeps no
    }
}}}

which seems weird as it suggests that global_options(ports_nodeps) is set to yes (equivalent to using -n) when it doesn't exist ... which would be the opposite of what's happening?


> > I agree, upgrade --force should imply only rebuilding the given ports.
> 
> Not if they have outdated dependencies. Upgrade without -n is a 
> recursive operation. Not passing the --force flag on to the deps by 
> default would be ok I guess, but what if the user wants that?

Yes, there's that. Using "upgrade --force" for reinstalling isn't really intuitive, so maybe it would be better to add an explicit reinstall command? It could probably still call macports::upgrade but forcing -n.
If the user really wants to reinstall a port and all its dependencies for some reason a -r option could be considered for making this (and other relevant) operation(s) recursive. In that case one can even consider depth control; I might want to rebuild, say, Kate5 and all the KF5 frameworks it depends on but not their dependencies (depth=1; not really a good example btw).

In short:
- certain actions are always recursive unless -n is given
- other actions apply to the given port(s) only, but could be made recursive over the port's dependencies, up to an optional depth.

A good example of that would probably be the uninstall action, where something like -r=1 would uninstall the target port's declared dependencies.

The big question would be whether it should be possible to combine -n and -r . I wouldn't mind that; each time I upgrade my KF5 framework ports I miss the possibility tell port to update just the declared dependencies of each of the meta-ports, regardless for instance of the fact I might have activated an older version of one of the indirect dependencies.

R