[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: policy regarding redistributable binary files in upstream tarballs



Hi,

Troy Benjegerdes:
> 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?
> 
Exactly: Get source by adding a vcs-git-commit: field which points to the
sources in question, instead of uploading a huge .tar.?z file.

> 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.

We usually do not *have* 15 releases. What we do have is updated source,
so the archive's mirrors would need to get five small files (the incremental
git .pack, its local and global indices, the new refs/heads/BRANCH entry,
and a tag created by the autobuilder) instead of one large and
mostly-redundant tar.xz.

A packed git repo is typically 10…20% larger than the .tar.gz it's built
from, so even with better compression via .xz this would be a win whenever
there's more than one source version in the archive.

I do plan to investigate this idea further. Sometime after the release.

-- 
-- Matthias Urlichs

Attachment: signature.asc
Description: Digital signature


Reply to: