On Wednesday November 18 2015 10:08:25 Rainer Müller wrote: > The registry lock needs to be taken when the action relies on the set of > installed ports. For example, when a 'port build' is running, you should > not be able to uninstall a dependency at the same time.
Frankly? That's a risk-less operator error that will be explained when the build command is repeated. It could be handled through an independent state or lock file that only disables `port uninstall` (or posts a warning with request for confirmation). I agree it's probably not ideal for (sub)average users, but how many of those are likely to run more than 1 port command at the same time? OTOH, anyone with usage advanced enough to prepare the build of a port while an install is running should be able to understand and cope with the kind of errors that might occur which only affect the failed command and not the whole MacPorts installation. Counter-example: what if I complained that I'm still being bitten regularly when I forget the -o option (or that I didn't use it in a running command) and edit a Portfile while it's being used, and find myself with weird errors because "base" decided to run a clean step between phases? Surely that's happened to anyone who's ever done some serious port development. The same thing would happen if you do a `port selfupdate` while a `port un/install` is running, but yet I don't think there's a protection against doing that. Or is there (it never occurred to me to try, strangely :)). I agree that there should be a lock that prevents concurrent access to the registry database, as that's something that appears likely to lead to registry corruption. If the registry lock were to be set when doing an (un)install or (de)activate, it'd be set very quickly when issuing `port uninstall` or `port deactivate`, right? R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
