4

For the last python project I developed, I used git as versioning system. Now it's that time of the development cycle in which I should begin to ship out packages to the beta testers (in my case they would be .deb packages).

In order to build my packages I need a number of extra files (copyright, icon.xpm. setup.py, setup.cfg, stdeb.cfg, etc...) but I would like to keep them separate from the source of the program, as the source might be used to prepare packages for other platforms, and it would make no sense having those debian-specific files lingering around.

My question: is there a standard way/best practice to do so? In my google wanderings I stumbled a couple of times (including here on SO) on the git-buildpackage suite, but I am not sure this is what I am looking for, as it seems that is thought for packagers that download a tar.gz from an upstream repository.

I thought a possible way to achive what I want would be to have a branch on the git repository where I keep my packaging-files, but this branch should also be able to "see" the files on the master branch without me having every time to manually merge the master into the packaging branch. However:

  • I don't know if this is a good idea / the way it should be done
  • Although I suspect it might involve some git symbolic-ref magic, I have no idea how to do what I imagined

Any help appreciated, thanks in advance for your time!

Community
  • 1
  • 1
mac
  • 42,153
  • 26
  • 121
  • 131

3 Answers3

4

why would you want to keep those out of the source control? They are part of the inputs to generate the final, built output! You definately don't want to lose track of them, and you probably want to keep track of how they change over time, as you continue to develop your application.

What you most likely want to do is create a subdirectory for all of these distribution specific files to live, say ./debian or ./packaging/debian and commit them there; You can have a makefile or some such that, when you run it in that directory, copies all of the files where they need to be to create the package, and you'll be in great shape!

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • There is a misunderstanding here: **I don't want to keep the files out of the source control**, I just want them **not to be in the same branch with the main code**. The reasoning is that if somebody wants to make a RPM, or pacman, or package, the debian files will only be "noise" to them: it would be more elegant to have separate branches for each packaging type, IMO. That said: sure, a script that copy/build/upload/delete is a possibility to keep the "noisy files" confined to a subdir. +1 ! – mac Sep 14 '11 at 05:51
  • 2
    the ultimate fate of a *branch* should almost always be *merge*. On the other hand, if I wanted to make an RPM; and I saw a folder for `./packaging` with several sub-folders, one for each packaging tool, that noise wouldn't be a problem. Actually, having to find the spec file by searching through branches would be *much more difficult* than any solution that doesn't work if i `find . -name \*.spec` – SingleNegationElimination Sep 14 '11 at 13:51
  • You have a point about the better "visibility" of a directory over a separate branch, although README files rule! ;) At the end - however - I settled for a makefile, based on the `git archive` command. Thank you for your time and input though! – mac Sep 23 '11 at 08:13
2

At the end I settled for a branch with a makefile in it, so that my packaging procedure now looks something like:

git checkout debian-packaging
make get-source
make deb
<copy-my-package-out-of-the-way-here>
make reset

If you are interested you can find the full makefile here (disclaimer: that is my first makefile ever, so it's quite possible it's not the best makefile you will ever see).

In a nutshell, the core of the "trick" is in the get-source directive, and it is the use of the git archive command, that accepts the name of a branch as an argument and produces a tarball with the source from that branch. Here's the snippet:

# Fetch the source code from desired branch
get-source:
    git archive $(SOURCE_BRANCH) -o $(SOURCE_BRANCH).tar
    tar xf $(SOURCE_BRANCH).tar
    rm $(SOURCE_BRANCH).tar
    @echo "The source code has been fetched."

Hope this helps somebody else too!

mac
  • 42,153
  • 26
  • 121
  • 131
0

You can have the extra files in a separate repo ( so that they are versioned too) and use submodules to use it in your source code repo.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • That seems essentially like the same approach of `git-buildpackage`: having a separate repo for the build, but this is not what I am looking for. If at all possible, I would like to have separate branches on the same repo... Is there a way to achieve that? – mac Sep 14 '11 at 05:57