On Sunday April 03 2016 19:01:57 Clemens Lang wrote:
> Sounds like SQLite was doing its job and failed at it. There's nothing
Or maybe it'd have take 2 months before succeeding...
> we can do from a MacPorts PoV on SQLite failing to recover.
I suppose that if anything there will be only an sqlite command to check
whether an fsck is going to be required, not if it'll succeed?
> Is there
> anything odd about your configuration that could cause problems with
> SQLite?
How would I know? I just know I hit ^C once, maybe twice, and then ended up in
this situation. Normally I don't have to restore the registry from a backup.
The only thing off with my installation is that `port provides` doesn't work,
but as far as I understand I'm not the only one in that situation (?).
> You suggested having a cron job that makes a backup. If an operation was
No, not cron.
> We're using a databse precisely to get this behavior. We shouldn't
> second-guess the database but fix the reason that causes the database to
> not provide this behavior.
>From what I understand sqlite3 isn't the most reliable alternative, but I
>think that topic already came up before.
> 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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
