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
signature.asc
Description: Digital signature
