[GitHub] [buildstream] abderrahim commented on issue #1460: Shouldn't use a cached failed build with a different strict key

[GitBox <gi...@apache.org>]

abderrahim commented on issue #1460:
URL: https://github.com/apache/buildstream/issues/1460#issuecomment-1046611910


   > Because the dependency of a library was not explicitly declared as a [strict dependency](https://docs.buildstream.build/master/format_declaring.html#expressing-dependencies), and in this particular case it perhaps should have been, given that the versioning information of the library is relevant in this case and causes errors down the line at build time ?
   
   I'd say it's not: bumping soname (that's what I meant by version) is not something that happens often, and making most dependencies strict is almost equivalent to the strict mode while being more verbose. So I guess it's something we should live with as it doesn't happen often.
   
   > Perhaps the problem is that bst artifact delete will only delete a single artifact, for which it has resolved the key for in the session of running bst artifact delete (was --no-strict also specified at bst artifact delete time ?), and does not provide any option to delete all locally cached artifacts for a given element ?
   
   Ok, I guess I wasn't explicit enough: I didn't delete the artifact, but I was expecting bst not to reuse it.
   
   So I have three elements: `app1.bst`, `library1.bst` and `library2.bst`. app1 depends on library1, which depends on library2. library2 bumped its soname, and library1 was built against the old soname. I'm building app1, linking fails because library1 needs the old soname of library2 which cannot be found (*). Up to this point, everything is as expected.
   
   I run `bst artifact delete library1.bst library2.bst` (deleting library1 only should be enough, but this is what I said above), then run the build again without the remote cache.
   
   At this point I expect the build to succeed, building all three elements. However, what happened is that it built the two libraries and presented me with the exact same error in (*) above. It was a cached failure, and answering retry on the prompt built app1 correctly.
   
   My point is that the second build shouldn't reuse the cached failure from the first one as they are different. So it should check the strict key rather the the weak key to determine whether to use the cached failure. I guess this would be even more problematic if it actually pulled the cached failure rather than having it already in the local cache.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@buildstream.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org