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

Re: dpkg source format 3.0 (git)

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

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.

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

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


Reply to: