Re: registry lock

On Wednesday November 18 2015 13:01:22 Rainer Müller wrote: >As I said, there is potential to allow certain operations with >fine-grained locking, but it requires more planning to get this right. >Just enforcing serialization of all actions that modify the registry is >the easy solution that

Re: registry lock

On Monday January 04 2016 16:18:54 Daniel J. Luke wrote: > The consequences of ignoring the lock (in the worst case) are worse than -n > -p or -o You're aware that the full path to the lockfile is already printed, almost as if to allow people who know what they're doing to copy/paste it into a

Re: registry lock

When using trace mode and armed with the dependency tree, I know that my concurrent installs will not be impacting each other. The lock should be intelligent enough to use the dependency tree�after all, MacPorts is the one computing it. I agree with Rene here: the lock should be smart enough to

Re: registry lock

On Jan 4, 2016, at 5:13 PM, René J.V. Bertin wrote: > You're aware that the full path to the lockfile is already printed, almost as > if to allow people who know what they're doing to copy/paste it into a > different terminal window and remove it. you're assuming a lot

Re: registry lock

+1 to making the locking work better -1 to René's idea of adding a 'maybe destroy your macports install' option. > On Jan 4, 2016, at 5:01 PM, Jeremy Lavergne > wrote: > When using trace mode and armed with the dependency tree, I know that my > concurrent installs

Re: registry lock

On 2015-11-18 12:52, René J.V. Bertin wrote: > 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

Re: registry lock

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

Re: registry lock

hat does not involve `port install`, `port > uninstall`, `port activate` and `port deactivate`. 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

Re: registry lock

On Tuesday November 17 2015 18:56:39 Ryan Schmidt wrote: >"port list" is a read-only operation; there's no reason why it would need to >set a lock nor be restricted by a lock. And AFAIK so is everything that does not involve `port install`, `port uninstall`, `port activate` and `port

registry lock

Hi, I may have asked before, so apologies if I forgot the answer: Why does "base" need a registry lock for operations up to destroot? I realise configure and beyond may require installing missing ports, but that could lead to locking the registry only when those ports are to be insta

Re: registry lock

On 2015-11-18 01:29 , René J.V. Bertin wrote: > Hi, > > I may have asked before, so apologies if I forgot the answer: > > Why does "base" need a registry lock for operations up to destroot? I realise > configure and beyond may require installing missing ports, but t

Re: registry lock

anything when we're not yet changing installed files? On Tue, November 17, 2015 13:36, Joshua Root wrote: >> I may have asked before, so apologies if I forgot the answer: >> >> >> Why does "base" need a registry lock for operations up to destroot? I >> realise con

Re: registry lock

On Wednesday November 18 2015 08:47:53 Joshua Root wrote: > > Exactly. Or the registry itself, for whatever reason that might happen > > outside of changing installed files. > > You're missing the point. Installed ports must not be changed by another > process even when the current one is not

Re: registry lock

On Nov 17, 2015, at 5:20 PM, René J.V. Bertin wrote: > On Wednesday November 18 2015 08:47:53 Joshua Root wrote: > >>> Exactly. Or the registry itself, for whatever reason that might happen >>> outside of changing installed files. >> >> You're missing the point. Installed ports must not be

Re: registry lock

On Tuesday November 17 2015 13:48:00 Jeremy Lavergne wrote: > So abstract a bit further beyond just uninstall phase: why do we need to > lock anything when we're not yet changing installed files? Exactly. Or the registry itself, for whatever reason that might happen outside of changing

Re: registry lock

On 2015-11-18 08:18 , René J.V. Bertin wrote: > On Tuesday November 17 2015 13:48:00 Jeremy Lavergne wrote: > >> So abstract a bit further beyond just uninstall phase: why do we need to >> lock anything when we're not yet changing installed files? > > Exactly. Or the registry itself, for