Hi zimoun, zimoun <zimon.touto...@gmail.com> writes:
> But the question is if Disarchive dissambles and preserves external > patches. Timothy? I have good news and bad news. :) The good news is that some versions of this patch are in the PoG database. There’s two versions of 0.76 and one of 0.72. Of those three, only the most recent has been identified and verified to be in the SWH archive (although now that they have ingested that whole repo, I should be able to add the other two). The bad news is that 0.75 is not there. At first I was going to apologize for the shortcomings of the sampling approach... until I realized you are trying to trick me! ;) Unless I’m misreading the Git history, that patch appeared and disappeared on core-updates and was never part of master. The way the PoG script tracks down sources is pretty robust. It takes the derivation graph to be canonical, and only uses the graph of high-level objects (packages, origins, etc.) for extra info. I do my best to follow the links of the high-level objects, and then verify that I did a good job by lowering them and checking coverage against the set of derivations found by following the derivation graph. Since the derivation graph necessarily contains everything that matters, this is a good way to track down all the high-level objects that matter. See <https://git.ngyro.com/preservation-of-guix/tree/pog-inferior.scm#n113> for a rather scary looking procedure that finds the edges of the high-level object graph. That being said, coverage is not perfect. The most obvious problem (to me) is the sampling approach. Surely there are sources that are missed by only examining one commit per week. This can be checked and fixed by using data from the Guix Data Service, which has data from essentially every Guix commit. -- Tim
