also sprach James Westby <jw+deb...@jameswestby.net> [2009.05.10.1523 +0200]: > With current practices there is effectively a "Debian upstream" branch > from the VCS, which contains thes history of the tarballs that made up > the source packages. > > Even when building from a VCS it is possible, and I would say > encouraged, to maintain this branch.
I've never done so, and I've never understood the need, but in the light of the autotools discussion, it's starting to dawn on me. Is this a separate branch with one commit per unpacked tarball, or is this a branch which gets upstream merged and then the tarball imported, such that the diff of that commit would effectively add all the changes and files introduced in the act of 'make dist' or 'make tarball'? > The above ensures that you get repeatability with the pristine-tar > information in case you need a -2 upload, and correctly represents > what happened in the case where there was some transformation done > to the VCS tree to get the tarball, as this transformation will be > in the diff between the imported tarball revision and the revision > that it was taken from. Good point, but I am not sure it's 100% necessary. pristine-tar is necessary, at least in the Debian context, but whether we have its xdiffs, or real diffs, I am not sure which to prefer. We're dealing with auto-generated files after all. pristine-tar abuses Git for storing the information necessary to recreate the auto-generated files, but it's doing so in a way that is not intrusive to the user. Asking the user to maintain a branch with auto-generated files does not have a clear-cut benefit for me. Am I just not seeing it? > I am aiming to make this process very easy in bzr-builddeb, as > I feel it should be *the* way to pull in new upstream changes. > (Upstream has released a tarball from a tag? Use that tarball > rather than a generated one. Upstream has no public VCS? Just > import the tarball without the extra parent.) The above, with the > exception of a transformation of the tarball, is all a single > command in the latest versions. I see your argument and the reasons for limiting the interface between distro and upstream to release tarballs, but doesn't that get in the way of cooperating on code and sharing patches, a benefit of situations where upstream and packagers use the same (D)VCS? -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the uncertainty principle: you can never be sure how many beers you had last night.
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss