Re: Rebuilds with unexpected timestamps [and 1 more messages]
On Tue, Nov 01, 2016 at 09:09:56AM +0800, Paul Wise wrote:
> On Mon, 2016-10-31 at 17:26 +0200, Adrian Bunk wrote:
>
> > At that point the best solution would be an alternative source
> > package format that is based on git.
>
> That already exists (see the dpkg-source manual page), but IIRC isn't
> allowed in the archive because the ftp-masters do not want to have to
> analyse the whole history of a git repository for DFSG issues.
Ie, we want the repositories pruned. Git supports incomplete repositories
just fine (aka shallow clones), although I'm not aware of existing tools
that would shape the pruning of an existing repository. You can "git clone
--depth=X" to a temp directory but that'd result in a flat repository. It's
trivial to emulate a primitive scheme like quilt with its linear stack of
patches, but why bother? Neither tarballs nor quilt are anywhere close to
being able to represent a preferred form for modification. Representing
that, ie, a non-linear history that enables both-way code transfers between
forks, meaningful bisect, etc, is much harder.
Even in this crippled form, though, it is strictly better than quilt: for
any given "3.0 (quilt)" source package you can produce a "3.0 (git)" package
that ships the exact same set of data bits (metadata differs).
Metadata-wise, both can ship arbitrary comments on patches; git doesn't
allow file timestamps but that's probably better than an _inconsistent_ set
of file timestamps: quilt preserves those on unpatched files but loses if
there's any change. Git also gives you hash references to commits you've
pruned, which you can then fill in from another repository. You also get
native signing for any commit.
Meow!
--
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.
Reply to: