as if your distro used git to maintain all of it.
You can then edit it,
-build updated binary packages
+build updated binary packages (.debs)
and install and run them.
You can also share your work with others.
=back
dgit clone needs to be told the source package name
-(which might be different to the binary package name)
+(which might be different to the binary package name,
+which was the name you passed to "apt-get install")
and the codename or alias of the Debian release
(this is called the "suite").
(For Debian afficionados:
the git trees that come out of dgit are
-"patches-applied packaging branches".)
+"patches-applied packaging branches
+without a .pc directory".)
=head2 What kind of history you get
=head1 INSTALLING
+=head2 Debian Jessie or older
+
=over 4
% sudo dpkg -i ../libc6_*.deb
you will get an error, which can usually be fixed with
C<apt-get -f install>.
+=head2 Debian Stretch or newer
+
+=over 4
+
+ % sudo apt install ../libc6_*.deb
+
+=back
+
=head1 Multiarch
If you're working on a library package and your system has multiple
You can use C<git push> to publish it on any suitable git server.
Anyone who gets that git branch from you
-will be able to build binary packages
+will be able to build binary packages (.deb)
just as you did.
If you want to contribute your changes back to Debian,
but don't care about its format/layout
(for example because some software you have consumes source packages,
not git histories)
-you can use this recipe to generate a C<1.0> "native"
+you can use this recipe to generate a C<3.0 (native)>
source package, which is just a tarball
with accompanying .dsc metadata file:
=over 4
- % git rm debian/source/version
- % git commit -m 'switch to 1.0 source format'
- % dgit -wgf --dpkg-buildpackage:-sn build-source
+ % echo '3.0 (native)' >debian/source/format
+ % git commit -m 'switch to native source format' debian/source/format
+ % dgit -wgf build-source
=back