+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 <[email protected]> > 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 <[email protected]> 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 +========================================================+ | *---------------- [email protected] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
