Muharem Hrnjadovic wrote: > pristine-tar's "gendelta" command does not check whether all paths in > the manifest are also present in the local/unpacked source tree.
Nor should it; pristine-tar gendelta can be run from anywhere; it has no knowledge about the source tree that will in the future be used by pristine-tar gentar. Which is why pristine-tar gentar has a documented requirement that the source tree it is run in have identical content to the original tarball contents. Including having all the files that are in it. > It thus generates a "broken" delta when something is missing from the > unpacked source tree (since not all the files required for generating > a pristine tar *later* are actually available). If you want this level of assurance, I think you should be using pristine-tar commit/checkout, rather than manually using gendelta/gentar. The difference is that pristine-tar commit *does* know exactly what tree will later be used be pristine-tar checkout. And so it can enable a hack that creates a dummy entry for missing files in that tree, which handles this case fine. Besides making pristine-tar gendelta fail if run outside a source tree, your patch has some other problems. It assumes that the manifest generated by tar always puts files in a subdirectory. A tarball that does not put all files in a subdirectory probably breaks it. Also, the tar-generated manifest sometimes contains filenames encoded in ways that pristine-tar does not understand, but tar does, and your patch would certianly fail then. -- see shy jo
signature.asc
Description: Digital signature
