Re: Ad-hoc survey of existing Debian git integration tools
Simon McVittie writes ("Re: Ad-hoc survey of existing Debian git integration tools"):
> Yes ish, but with the orig/diff structure the way it is, the preferred
> form for modifying a non-native Debian package seems to be the tree
> representing the unpacked package, plus the orig tarball (or enough
> information for e.g. pristine-tar to recover it) - just having the tree
> will give you a package that technically works, but can't be uploaded as-is.
With just the tree, with an appropriately-shaped git history, you can
- build, install and run
- modify in any way you like
- represent your changes to upstream in a clean way
- share with other people (who can all do all of the above)
The /only/ thing you can't do with it is upload it directly to a
source-package-based archive, without first obtaining suitable orig
tarballs. If you are uploading a new debian revision, rather than a
new upstream version, dgit fetch will obtain a copy of the archive's
current orig tarball and place it where build and push will find it.
> Being dogmatic about "the source, and only the source" is arguably a
> good thing; the orig + diff structure is arguably a good thing; and
> universal adoption of dgit seems like a good thing. I don't currently
> see a way to get more than two of those three at a time.
There are two reasons for the orig+diff structure, which are quite
different:
One is that it saves a lot of archive space. This is far from
insignificant.
The other is that it allegedly provides a conveniently verifiable
format for finding out what Debian is basing its stuff on, and what we
have changed. OTOH, now there are many different source formats, and
many maintainers are using a format so complicated that it can't be
unpacked other than by dpkg-source and can't be inspected easily by
hand. It's getting to the point where a comprehensible git branch is
better for many purposes.
Thanks,
Ian.
Reply to: