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

Re: [PATCH] proposed v3 source format using .git.tar.gz

Anthony Towns wrote:
> Is a .gitdiff.tar.gz possible, so the archive doesn't need to have the
> full git repo replaced by each upload? ie, something like
> 	Files:
> 	 .... foo_1.0-1.git.tar.gz
> 	 .... foo_1.0-2.gitdiff.tar.gz
> so that a small patch only adds a small file to the archive rather than
> replacing a large one?

I think it's possible, the gitdiff might use git packs against a prior
repo. That would be a nice enhancement to what I have done.

> This means you can't build the package by hand with standard unix tools
> -- at the very least you need git installed, and if other VC systems
> are to be supported, you need them too.

Yes, as I mention in the faq I think this is an acceptable tradeoff to
get away from having to use diff.

> Changes in repository formats will presumably result in versioned
> dependencies too.

I don't think that dpkg should add vcs formats that we don't have a good
expectation of remaining supported by newer versions of the tools going
forward (so svn repos are out). There's a bit of discussion of this in
the faq. I think that git has a pretty good track record and has
incentive to keep compatibility support since this format is
used over the wire by git (eg, with http urls).

If the format changes in a non-backwards compatible way, we could have
source packages built on unstable that cannot be extracted on stable,
which I also think is suboptimal, but hard to completly avoid.

> This is slightly worse than the case for existing patch management tools
> in that most of those can be dealt with by hand; though cdbs and to a
> lesser extent debhelper can't be quite as easily replicated I guess.

Neither could packages using quilt before it was available in
stable or dbs before it was.

> Once the unpack is done, I don't see any reason why you can't do an NMU
> in the traditional way, so presuming "dpkg-source -x" or "apt-get source"
> handles the unpack automatically, I don't think it necessarily imposes
> any new requirements on NMUers.

Basically, you have to know how to git commit your changes before building
the NMU, and that's all. As a bonus, it's rather easier to generate NMU
patchsets. :-)

> Maybe providing a feature on packages.debian.org (or similar) to download
> sources in simple, non-VC, tarball format would make this a complete
> non-issue though?

pristine-tar could be used for this, it would just need source packages
to put the delta somewhere standaised (under debian/), and would need 
some standarised way to get to the upstream source branch in git.

> Would it make sense to have the source format look more like:
> 	Format: 3.0
> 	Source: dpkg
> 	...
> 	Source-Depends: git-dpkg (>= 3.14159)
> 	Source-Hooks: /usr/bin/git-dpkg
> 	...
> 	Files:
> 	 ... foo_1.2.git.tar.gz
> and have the git specific functionality be provided by a /usr/bin/git-dpkg
> binary (with standardised arguments) from the git-dpkg package? That
> would let you smoothly deal with repository changes and implementing new
> interfaces, and also let us limit the allowable formats for the archive
> reasonably simply.
> You could drop the Source-Hooks: line, and just have dpkg-source know
> to associate *.git.tar.gz with /usr/lib/dpkg/source/git, and trust the
> package will provide it.
Not sure if this buys anything that using perl modules for the vcses
can't do, really. How do you envision this helping deal with repository
format changes?

> Bonus points: rather than "debian/rules clean, create a diff, build",
> have dpkg do "debian/rules clean, commit any uncommitted changes with the
> commit message being the changes from the changelog, create a .git.tgz,
> build" for git-source-format packages.

I have a feeling that any auto-commit stuff should be controlled by an
option. I'm *sure* that it would annoy some developers. No strong
feelings about whether it should default on or off, though least suprise
suggests *off*.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: