On Fri, Nov 21, 2014 at 10:25:43AM +0100, Matthias Urlichs wrote:
> 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
I think the reality these days is 'github' is often the pristine source, and
the tarball is much more like a binary package. So to get that audit trail
and tracking that was mentioned in this thread we probably need to have a
debian-ized fork/mirror of the upstream VCS, so long as it's a VCS that's in
debian.
How hard would it be to add hooks/helpers to dpkg-buildpackage to know how
to deal with git and mercurial repositories, and deterministically generate
the 'source' tar.gz from the repo?
If you take this approach a little farther, I think there's an argument (I
am not sure it's a good one yet) that the debian source archive will take
up quite a bit less space if it's using git/mercurial repositories that can
store a single copy of the same file that's used in 15 different releases,
while the current approach makes 15 copies in the source packages.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' ho...@hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141122151513.gd29...@nl.grid.coop
