Debian packaging

[coldtobi]

(This in reference to http://bugs.thedarkmod.com/view.php?id=4360 where greebo and I discussed already and then decided to move the thread over here.)

 

Quoted here again for conveniene

 

greebo:

 

By the way, tobi, if there's anything I should change in the sources in order to make your life as packager easier, please let me know. I saw that you changed stuff in debian/copyright etc. - is that something I should be pushing to upstream?

 

 

 

tobi:

Thanks for asking!

Regarding the Debian directory:
If you want, you can sync back the changes to the debian/ directory, but it won't make a difference for the packaging (@Debian we usually recommend that upstream do not ship a Debian directories, but our packaging tool will ignore the directory e.g if I import a new version*). However, the debian directory in the github repository is a quite old packaging style, so it wouldn't hurt to update them; though you need to see if you want all the changes, e.g I did drop the i20n package.

Another wish:
I'm currently carrying a patch to make darkradiant builds reproducible, (http://reproducible.debian.net/ [^]). I did not yet bother to submit it to you, as it is qwritten uite Debian specific. Though, maybe you want to take a look and eliminate all __DATE__ and __TIME__s? https://anonscm.debian.org/git/pkg-games/darkradiant.git/tree/debian/patches/01-reproducible-build.patch. [^]


* BTW, there is a wiki page for upstreams, which might be a interesting read:
https://wiki.debian.org/UpstreamGuide; [^] But you're doing fine here, as far as I can see..

 

 

greebo:

Ok, I just tried to merge changes from your repo (https://anonscm.debian.org/git/pkg-games/darkradiant.git [^]) to mine, but it produced tons of conflicts. Is the repo at debian.org a clone or have the files been imported by copy?

What's the best approach to make the __DATE__ stuff compatible with the repro builds? I'd like to have some sort of timestamp in the app since that's the only thing I can get from some users in terms of info. I usually don't bump versions for pre-release binaries handed out for testers.

Is it possible to define a build timestamp for Linux builds at the time the ./configure script is run? Or is that even worse?

As far as the Debian folder goes - I'd be perfectly fine with giving you write access to the repo at github such that you can work in the upstream repo directly without applying the same things over and over again each time you look into packaging. Since you as a packager are doing work that would otherwise be left for me to do, I'm willing to make your life easier here.

 

 

(I will follow up later)

Edited January 2, 2017 by coldtobi

[coldtobi]

Ok, I just tried to merge changes from your repo (https://anonscm.debi...darkradiant.git [^]) to mine, but it produced tons of conflicts. Is the repo at debian.org a clone or have the files been imported by copy?

 

 

 

 

Debian's repository is based on the release tarballs (importing them into the repository with git-buildpackage), so there is no direct relation between your and the repository I use.. This is probably the reason why it won't merge

However, I can try to come up with a PR to bring up the debian/ accordingly, but this will take me a while due to some imminent buisiness trip..

See also below.

 

What's the best approach to make the __DATE__ stuff compatible with the repro builds? I'd like to have some sort of timestamp in the app since that's the only thing I can get from some users in terms of info. I usually don't bump versions for pre-release binaries handed out for testers.

 

Is it possible to define a build timestamp for Linux builds at the time the ./configure script is run? Or is that even worse?

 

I understand your requirement... However, I'd discourage to recycle version numbers.. Some ideas:

• Maybe something like git-describe* to generate some version string at build time, at least when there is a git repository (on the Debian buildds there won't) (* or maybe using autorevision https://autorevision.github.io/)
• Ignoring the issue for your builds -- (the patch required for this is tiny, so I can carry it in Debian only, and it might be indeed already fixed by newer gccs: https://reproducible-builds.org/specs/source-date-epoch/ -- I did not test this though)
• Using __DATE__ only for debug builds / pre-release (by definging some macro at configure time and using those __DATE__ __TIMES__ only if that is #defined.

 

As far as the Debian folder goes - I'd be perfectly fine with giving you write access to the repo at github such that you can work in the upstream repo directly without applying the same things over and over again each time you look into packaging. Since you as a packager are doing work that would otherwise be left for me to do, I'm willing to make your life easier here.

 

No need for me to have write access to the repo

Also note that Debian's tools are smart enough to ignore any "upstream" debian directory, so when I pull in a new tarball from you your's will just be ignored..

(At least for the tools I'm using .. some other toolchains get a bit more complicated when there is a debian directory.)

The Debian's upstream guide recommends this, though, as said, for me it is ok as it. (Even if get out of sync,it won't get unusuable soon to self-compilers.)

 

Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default if it lives in a specific packaging branch, which mimics what Debian package maintainers do using git-buildpackage. Though leaving the debian folder in the normal branch can also interfere if the package maintainer is using an upstream git packaging workflow (for example: git tag based git-buildpackage workflow).

 

Tobi

[greebo]

I'll try to rethink the numbering of pre-release builds, I guess. Still, I want users to immediately recognise a pre-release build as such. And I'll get rid of the build date in the code to save you from patching the tarball.

 

I'm not a fan of odd/even versioning schemes some projects have (wxWidgets, or GTK+), where stable releases get 2.8.x and unstable releases become 2.9.x, with 2.10 being the next stable one. Or only mentioning it in the release notes that this version is stable and the other one is not. Every project appears to have different versioning schemes and I don't want users to learn that scheme to know what's what.

 

The current public DarkRadiant release is 2.1.0, the next one will be 2.2.0 as there are new features already in git. I'm leaning towards versioning the pre-release builds as 2.2.0, but tagging them as pre1, or beta2 in the actual version string.

 

How often are you going to package something for Debian? You probably don't want to package pre-release builds, am I right? Maybe all this pre-release build versioning doesn't affect you that much.

 

Re: debian folder: as long as it doesn't hurt your packaging process I'm going to keep it even if it's somewhat out of date, should I ever need to build a .deb package myself. I wouldn't want to build it from scratch in that case. As long as there aren't any actual mistakes in those files I'm going to occasionally bump the version or update the changelog perhaps. If there are mistakes, please just point them out and I'll try to fix them right in source.

[greebo]

For the records, the __DATE__ and __TIME__ macros are now used for the Windows target only, so the Linux compilation should no longer be affected by this (with commit 9dbf788)