<thomasd>fps: Maybe (probably) I still misunderstand your idea, but in the example from yesterday, where A depends on B, B is updated, so we have A' <- B'.
<thomasd>as I understand it, the idea is that, if A', modulo embedded PATHS etc turns out to be bit-identical to A (e.g. in case where B is a C library and B' is ABI-compatible with B), it could be detected and A' could be generated from A by "automatic grafting"
<thomasd>my comment was that such a thing is hard to predict in advance (i.e. without building B' and A' and checking the results), but AFAIU Guix must be able to calculate the dependency graph from the package descriptions alone,
<thomasd>so to conclude my monologue :-) : I think guix devs would have to keep track of ABI versions of packages, and embed this information in the package descriptions to make it work. Seems hard to to in an automated way.
<erliphant>what's the link between a package definition and the substitute location? How does guix determine the url for the substitute?
<lfam>erliphant: By substitute URL, do you mean the URL of the substitute server? Or something more specific?
<methalo>hi lfam, i'm trying fix fails for ustr package on core-updates, but the project appears hasn't been active since 2008!
<erliphant>lfam: I mean the actual path. I know that the substitute server can be provided to either the build command or the daemon but how does it work out what file to request from hydra or the guix publish server
<lfam>erliphant: I don't know the details, sorry :) I'd start by looking in 'guix/scripts/substitute.scm'
<erliphant>lfam: I've got a package in gnu/store but it's not served up by guix publish. I think I'm missing something
<methalo>lfam: i found a patch for the Debian project