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 there.
> An option to ig
+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 will not be impacting each oth
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
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
On Jan 4, 2016, at 4:13 PM, René J.V. Bertin wrote:
> Maybe the "simplest" solution would be to provide an option to ignore the
> lock if it's present, and leave it to the user to know what s/he is doing
> (and assume the consequences, like with -n, -p or -o)?
that's a pretty horrible idea.
Th
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 works
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 uni
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)instal
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?
ing that 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 depend
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 deactivate
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 cha
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 ch
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 whatever
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 installed
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
>> realis
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
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
18 matches
Mail list logo
