alkisg: i need to update mkdst to support basically what i've been doing with a little script of mine.

17:22

alkisg: there's nothing inherrently debian about it?

17:22

<alkisg>

Ah, that's reserved for packages developed *only* for debian?

17:22

<vagrantc>

alkisg: and if you make minor changes to packaging, it uses the same tarball in the archive

17:22

<alkisg>

Not the deratives too?

17:23

<vagrantc>

well, derivatives do whatever they want, but it makes it harder for derivatives to release differing versions

17:23

i.e. the -0ubuntuX versions

17:24

<alkisg>

Yeah my plan is that I'm too stupid to understand all that so I want the derivatives to tell me what they want to do different so I can put "if"s in the code and release a new version with those :P

17:24

Haha

17:25

Kidding aside, will that mkdst thing also help in getting the version from the changelog and putting it to the source code for e.g. epoptes-client --version to work without manually changing it each time?

17:25

<vagrantc>

alkisg: might be simple enough to set up a bzr-release target in (ironically) debian/rules that creates the new upstream tarball.

17:25

as long as it's not automatically called during build.

17:26

<alkisg>

Sounds fine to me

17:26

<vagrantc>

alkisg: you could have the build process dump a version file somewhere

17:26

<alkisg>

Is that better than sed'ing the version in the source?

17:27

(thinking of python's __init__.py, which also contains the version...)

17:28

epoptes/__init__.py:__version__ = "0.4.3"

17:28

Maybe setup.py could do all that?

17:31

tcos-configurator has code for that... it even uses __VERSION__ in its headers, I suppose it's substituted by setup.py automatically