Hi, Russell Stuart: > Admittedly this meshes well with my experience that they are often > fairly lax about what they put in those tarballs. Their "make > distclean" scripts are often not as good as they could be Or they're better, in that a "make distclean" removes files like *.min.js which a subsequent "make" does not rebuild even if the unminified source is there, which it frequently is not. > That's just me being lazy I guess. But there is a deeper issue. For me > it is vital there be an audit trail from the pristine upstream tar ball > to the binaries we distribute. These days, they might just push their repo to github and let its machinery generate the tarballs, which TTBOMK aren't guaranteed to be 1:1 identical to another tarball of the same commit that's downloaded a week later. Or a year. > [b] Add a section to the .dsc (say Pristine-Sha256) that contains the > URL's and hashes from step [a.1]. > Or one that contains the upstream VCS repo's URL and commit ID? NB: *URLs. > [4] Unpacking to a separate build directory neatly sidesteps several > Debian nits. So would having the Debianized source in a VCS; then you can just tell it to return to pristine state (git reset --hard && git ls-files --others -z | xargs -0r rm -f). -- -- Matthias Urlichs
Attachment:
signature.asc
Description: Digital signature