Raphael Hertzog writes ("Re: Introducing dgit - git integration with the Debian archive"): > I'm sorry to have missed that impromptu BOF at debconf, I would have > definitely arranged myself to be there if I had known its existence.
Yes, sorry about that, but it was arranged ad hoc at zero notice. > I don't think that "3.0 (quilt)" does things without justification so > calling those features "braindamage" is not really nice. Clearly the > quilt format duplicates some of the VCS features (with its .pc directory) > and this is probably what you are referring to in the above paragraph. The thing that really bothers dgit is that it is not always possible to round trip a tree through dpkg-source. (And the case where it doesn't work is the common one.) That is, if I do this: 1. dpkg-source -x 2. edit things 3. dpkg-source -b 4. dpkg-source -x on the output from stage 3 then the output of step 4 is not always the same as the input to step 3. Typically the output of step 4 has additional metadata files inside the tree. It seems to me that the most fundamental requirement for an archive format of any kind is that packing something into the archive, and then unpacking it again, should give you back what you started with. > That said I have always thought of the "3.0 (quilt)" source package as > something that we should be able to generate ouf of a VCS tree, not > something to be directly stored in a VCS repository. With dgit, at the moment, all that happens is that the gitish changes get piled into the dpkg-source-generated patch. For some more sophisticated workflow, it is necessary to round trip the patch stack through the archive and back into git. > In any case, I'm open to suggestions to improve the format to better suit > your needs... so can you can explain me more precisely what's causing you > issues? Either here or better in a bug report against dpkg-dev. Ideally, packing something up and then unpacking it again should not produce changes. NB that if you change this you absolutely must not change the meaning of existing source archives - ie you can make changes to the packing algorithm but not to transformation implied by the unpack algorithm. > I would really like to find a good workflow that suits "3.0 (quilt)". > Badly supporting half the archive looks like a problem. The support is no worse than NMUs are now, from the maintainer's POV. >From the git POV you just see a git history of some kind and commit on it. > BTW, instead of advising against "3.0 (quilt)" you should rather recommend > the usage of the --single-debian-patch option when using that format... > this will make it mostly work like "1.0". This is a command-line option ? How does one specify in the source package that this is to be used. > I have read the manual page but there some things that I don't really > understand on the design yet. So let me ask some questions: > > - is there some server side part (running on alioth)? > what does it take care of? Yes. It is a git repository. That is all that it is. > - what/who creates the initial repository? and what/who keeps it in sync with > the (non-dgit-based) archive uploads? The repos are created only by dgit users. Different dgit users see the same commits from the archive: the synthesised commits are deterministic. In the future there might be a robot keeping it in sync with the archive. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21015.18345.930607.890...@chiark.greenend.org.uk