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