registry lock
Daniel J. Luke
dluke at geeklair.net
Mon Jan 4 14:16:58 PST 2016
+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 <jeremy at lavergne.gotdns.org> wrote:
> 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 use the
> dependency tree.
>
> On 01/04/2016 04:18 PM, Daniel J. Luke wrote:
>> On Jan 4, 2016, at 4:13 PM, Ren� J.V. Bertin <rjvbertin at gmail.com> 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.
>>
>> The consequences of ignoring the lock (in the worst case) are worse than -n -p or -o
>>
>> if you want to improve the locking, I'm sure everyone will be happy about that. If you want to hack your system to not use the lock, you can live with the consequences - but it's not something we should ship.
--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
More information about the macports-dev
mailing list