Re: dpkg source format 3.0 (git)

[Goswin von Brederlow <goswin-v-b@web.de>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Goswin von Brederlow wrote:
>
>> 1) Think about doing this for linux-2.6, XOrg or OOo and what it would
>> mean for the source size or usability.
>
> Indeed, the history is pretty large.  A rough estimate (for something
> less rough, one should use a well packed bundle with only the objects
> of interest):
>
>  $ pwd
>  /home/jrn/src/linux-2.6
>  $ git status -u
>  # On branch next
>  nothing to commit (working directory clean)
>  $ du -sk .git
>  440664  .git
>  $ du -sk --exclude=.git .
>  450920  .
>  $ du -sk ../linux-2.6.33-rc7.tar.bz2 
>  64648   ../linux-2.6.33-rc7.tar.bz2
>
> The source package would become about 7 times as large.
>
> For usability: I imagine what is typically needed is the set of Vcs-Git
> fields somewhere conveniently machine-readable, so one could just go
>
> 	apt-get source --git whatever
>
> and get a checkout of its packaging repository.
>
> That would be the 90% solution.  What it doesnâ??t do is help people with
> poor connectivity to hack on a package like linux-2.6.  Given the high
> quality of commit messages and the sparsity of comments on the
> implementation, it is really much easier to work with the history in
> hand.

Then create CD/DVDs of git.d.o.

> So it would be nice (though hard) to find some method that allows the
> git history to be widely mirrored, included on distributed DVDs, and
> so on.  Iâ??m sure the admins of kernel.org would appreciate it as
> well.

Show the demand and I'm sure mirroring will follow.

>> Uploading a new source could then be sending a signed ref to the
>> maintainers git or sending a signed bundle or even just pushing and
>> setting a tag.
>
> I imagine that would be very nice for people with large packages.
> Maybe something similar could be accomplished for existing
> tarball+changes packages by providing a "proxy" git server that runs
> dpkg-source -b server side.

For non-upstream updates the upload is usualy small. Just the diff.gz or
debian.tar.gz file. But yeah, for most upstream changes a pristine-tar
upload is much smaller than the full orig.tar.gz. But is that really the
problem?

> Selfishly, I guess if someone implements the 90% solution above, I
> would stop caring so much about what source format the buildds use.
> Others might be more principled, though. ;-)
>
> Regards,
> Jonathan

MfG
        Goswin