2

I have a bunch of helpful utility scripts under a personal private repo on git where I have not bothered with branches/tags etc as the were not necessary.

Recently I thought I'd see about creating debian packages for some of them, my current build process is:

  • Create directory package_name-version.
  • Copy binary and man page from repo location to this location.
  • dh_make --createorig
  • setup copyright/changelog/install/control/manpages files within created debian/ dir
  • dpkg-buildpackage -rfakeroot

I was reading more and came across git-buildpackage realising it could create the changelog from the git commits and tags, make the whole process simpler and have it properly versioned.

I've extracted the script and manpage to another repo by:

cd /path/to/old-repo 
git format-patch --stdout --root -- <path> >~/patches 
cd /path/to/new_repo 
git am ~/patches

so now in the new repo root I have a script and manpage.

I've looked at https://wiki.debian.org/PackagingWithGit which mail seems to dealing with repos already configured for doing this as it's referencing .orig.tar.gz files and upstream releases.

I'm struggling with understanding how to change the structure of my new repo (with a script and a manpage) to what it should be.

I understand I need to alter the structure, create tags for versions, create branches but not sure of the structure and git commands.

If anyone can provide assistance in this or outline the entire process it would be appreciated.

Sorry for the length.

bignose
  • 30,281
  • 14
  • 77
  • 110
Alasdair
  • 566
  • 1
  • 4
  • 16

1 Answers1

2

There are a lot of different ways to use the git-buildpackage tool for managing a project. It sounds like in your case, you have no particular need for keeping track of precise orig tarballs. You don't need to use the parts of https://wiki.debian.org/PackagingWithGit that talk about .orig.tar.gz files or upstream releases. That document seems mostly concerned about good ways to import/track/merge upstream source, but you are the upstream.

The only git repo structuring that matters in your case, that I can think of, is that git-buildpackage expects your project to be at the toplevel. That is, the debian/ dir should be a toplevel directory in the repo, and a sibling to the .git directory.

You probably also want to mark your package as being a "native" one, meaning there's no need to track orig tarballs separately from the debian packaging. To do this, use debian package versions without a debian revision number (no "-N" on the end) and

echo "3.0 (native)" > debian/source/format

The git-buildpackage manpage and the manual, found at /usr/share/doc/git-buildpackage/manual-html/ or online here, will probably be the best source of further information.

the paul
  • 8,972
  • 1
  • 36
  • 53
  • not sure what you mean about the debian/source/format as this file is missing. As it's bash scripts there is no source (or everything is source depending on your viewpoint) as nothing is compiled. One other thing, was looking into bash completion. Should these completion script just be sourced to /etc/bash_completion.d/ or output from postinstall? Also how do I combine rules e.g. _known_hosts and _filedir_xspec as in if completion cannot match a host try a normal file. – Alasdair Jul 29 '14 at 17:29
  • 1
    you should create the `debian/source/format` file. yes, bash scripts are certainly source in this context. if you have a separate question about bash completion, you should post it separately. – the paul Jul 30 '14 at 18:17