On Mon, Feb 11, 2008 at 12:48:19PM +0100, Raphael Hertzog wrote: > I believe the wig&pen format [1] solves most of those concerns. I believe > that with some minor changes, it would satisfy the need of most packages > (even those using complicated build system). > But the complicated part comes when we try to think of interactions > between VCS and source package format. I think it's a mistake to separate those -- our source package format is a VCS system; if wig&pen happens to be a more suitable VCS, that's fine, but it's not inherently superior or inferior to any other VCS, just because it happens to be Debian-specific. If you look at it that way, then instead of having a ".git" directory with metainfo about the package, you have a "debian/patches" directory (and some tarballs in ../ probably); instead of a dpkg-source plugin that generates a .git.tar.gz you have a dpkg-source plugin that generates a set of wig&pen tarballs. > I'd like to keep the (default) > source package format mostly VCS agnostic If you think about it that way it's meaningless to say the source package format is "VCS agnostic" -- it _is_ a VCS all on its own. > - dpkg-dev (or dpkg-dev-vcs) provides VCS-specific scripts in > /usr/share/dpkg-dev/ that can be used to generate a wig&pen source > package from a VCS repository ie, "that can be used to covert from the VCS used in development to wig&pen VCS". Note that VCS conversion is harder (and slower) than it looks. > - the package's repository contains a debian/source.rules that provides a > target "build" to create the wig&pen source package, You shouldn't need to write any code to create a source package -- that's what dpkg is for. > - note that debian/sources.rules could support a "build-v3" target that (Ugh...) > - also note that we can have several variants of the build scripts even > for a single VCS (think one using feature branches and one that doesn't) The git way of looking at that would be "same scripts, but different branch"; the debian/patches way of looking at it would be "same scripts, but different patches enabled". Other VCS'es would probably require a different checkout/source package entirely (CVS, darcs). That shouldn't need per-package code (in debian/rules or similar), just per-VCS code (eg, "git branch"). > - in any case, I suggest using the Build-Options: field discussed several > times already (#229357) to let the dpkg-source know that the package supports > the new source format (instead of using a dedicated field) And afaics it's not really something you can do automatically (ie, you need a human to decide if you want to use the "experimental-featureset" branch on a per-package basis), so shouldn't need any new options, afaics... > I plan to write code in that direction: > - add the API required for wig&pen > - make dpkg-source be able to generate wig&pen source package > - then add some scripts that use the wig&pen API to generate source > packages from a VCS directory > Comments are welcome. So far, wig&pen has objectively failed as a source format; please let the git/bzr/etc format succeed or fail on its own merits, without tying it to a wig&pen resurrection attempt... Cheers, aj
Attachment:
signature.asc
Description: Digital signature