Are FORCE and FORCE-NOT semantics right?

[Robert P. Goldman]

The manual specifies that FORCE takes precedence over FORCE-NOT, and a half-baked test by me seems to indicate that this is right.

Is this The Right Thing? I would imagine a common case is that someone wishes to rebuild all of the dependencies of some system, with some chosen exceptions. This is what suggested the issue to me, because I wanted to rebuild a system of mine on SBCL. My system depends transitively on SB-GROVEL, which is a built-in, and cannot be rebuilt by a normal user, since it's installed in /usr/local.

So it seemed like (asdf:load-system "foo" :force t :force-not (list "sb-grovel")) would be just the ticket. Unfortunately, if the manual is correct (and behavior of SBCL 1.1.7+ from git suggests it is), this cannot be done.

Is there any reason why the precedence shouldn't be FORCE-NOT overriding FORCE? I.e., build blocking being winning over building?

[Faré (fahree)]

Note: closed duplicate bug #1227261

[Faré (fahree)]

You are right indeed: both the case you cite (amendment to :force :all) and the case by Erik Pearson that prompted the feature (don't recompile systems in the dumped image) are about knowing a list of systems for which you trust the current image more than the filesystem and/or filesystem access is going to be painfully slow, at which point the force-not should take precedence over force.

My apologies for not thinking this matter through before.

[Faré (fahree)]

A persistent default to :force-not, and/or a list of systems that is merged to it or a hash-table consulted in addition to it, might also provide a real solution to this formerly erroneously(?) closed bug, a case similar to that of Erik Pearson:
  https://bugs.launchpad.net/asdf/+bug/604728

[Faré (fahree)]

OK, fix committed in 3.1.0.89, including a new variable *immutable-systems*. Enjoy!