Re: Introducing dgit - git integration with the Debian archive
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.
Reply to: