Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Debian and Ubuntu Packaging for the d-rats application

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
README.gitmethod

README.gitmethod

I learned this method from Bdale Garbee

Note: These are mostly my (sconklin) personal notes. If they are helpful to you that's nice, but they aren't really intended to
be high quality documentation.

--

The tarball from upstream for d-rats contains a non-free (or questionable) executable. That needs to be stripped form the tarball

bdale: I do all of my packaging in git, so I think about this in terms of git branch management.  Before I used git for packaging, I did a lot of this "manually".  So let me explain how I'd handle an upstream with non-free content in git and see if that makes sense to you?

sconklin: yes, please.

bdale: ok, so I'll use 'tar' as an example, because it's suitably complicated to cover all the interesting cases

bdale: I have a branch structure that includes upstream, pristine-tar, dfsg-orig, dfsg-debian, doc-orig, and doc-debian branches to start

bdale: when there's a new upstream release, I download the tarball, and import it into the upstream branch with commands like:

bdale: git checkout upstream
bdale: git-import-orig --no-merge --pristine-tar --upstream-version 1.23 ~/Desktop/tar-1.23.tar.gz

bdale: this gets us the upstream 1.23 sources into the upstream branch, doesn't try to automatically merge them down anywhere, and puts the tarball into the pristine-tar branch .. 

bdale: then I want to merge this into the dfsg-orig branch, clean it of non-DFSG compliant stuff, and commit it... so I do something like:
  git checkout dfsg-orig
  git pull . upstream     # See NOTE just below
  ./cleanup-script.sh
  git commit -a

NOTE: In the case of d-rats, the cleanup script removed the directory libexec and the file in it, so this directory no longer exists on the dfsg-orig branch.
Git ignores empty directories (and apparently those which do not exist), so when you do the pull that directory won't be created, and you don't need to run the cleanup script or commit. BUT - make sure nothing new has been added to that directory upstream. If it has, you'll have to get it.

bdale: the cleanup-script.sh exists only in that branch, and basically removes the doc/ subtree followed by unpacking a shar containing a skeletal Makefile.in and README to keep the build system happy without further patching and explain to the naive what's going on

bdale: so, now we move to the dfsg-debian branch, populate the debian/ directory, create a debian/gbp.conf that tells git-buildpackage to use dfsg-orig as the 'upstream' branch and dfsg-debian as the 'master' branch for packaging, and go for it..  since we don't have an orig.tar.gz matching our cleaned upstream, we create one like:

    git checkout dfsg-debian
    git pull . dfsg-orig
    - fix up merge conflicts
    - update debian/changelog
    git commit -a
    git-buildpackage --git-ignore-new --git-no-pristine-tar -S
    pristine-tar commit ../build-area/tar/tar_1.23.orig.tar.gz

    rm -r ../build-area/tar/*
    sudo cowbuilder --create # optional if needed the first time
    sudo cowbuilder --update
    git-buildpackage
    git tag debian/1.23-1

Now for Ubuntu: (Note: Ubuntu branches are temporary until debian is in place)

git checkout dfsg-ubuntu
git pull . dfsg-debian
(fixup changelog)

Note: Versioning for Ubuntu must be like this:
   0.3.3~b5-lucid07

git-buildpackage --git-no-pristine-tar -S -sa

And repeat for the dfsg-ubuntu-maverick branch


bdale: sconklin: so you can see, I'm making use of git, git-buildpackage, and pristine-tar .. and the results are just stunningly productive once you get the mental firmware in place to just "do it"

bdale: and by doing *all* of my package builds in cowbuilder, I never ever get caught with bad build-depends content on an upload... though the price I pay is waiting for the "populate a minimal chroot" to happen on every build.  it's completely rational to use more efficient build cycles and just do this for things you're going to upload, but I'm OCD about it.

bdale: for Debian packaging, using git.debian.org via the Alioth collab-maint thing can be a good choice

bdale: I have enough other git stuff going that I tend to just use git.gag.com and let others cope, putting appropriate tags in the debian/control file to show where my packaging repo is, etc

bdale: my only other suggestion, which I'm bad at following myself, is to put a debian/README.source or whatever it's called in place that does things like document the branching structure you're using and a canonical set of steps like those I pasted above.

sconklin: easy, I can paste a chat log in as a start . . . ;-)

Something went wrong with that request. Please try again.