This page is a discussion place for the choices of the tools used in the Debian Games Team
Please add your answers, reasons and name for each question
If you are in a rush, you might want to jump to the conclusions (no pun intended).
TopGIT: Should we allow/require TopGIT for «patching» gitmaintained packages
Using an already set up TOPGit System is really straight forward, it helps documenting the patches, has explicit dependencies between them and is more natural to use in an git-repos. So I think we should allow TopGIT for our packages.
I'm not sure we should force it, however. Git+Quilt is working and is similar to the svn process.
If we decide to not use TopGIT later we can even go back easily so this has no long-term implications
I would allow it but not make it mandatory. Splitting patchsets and putting them into branches is a good idea no matter if you do it by hand or via topgit, though.
Gonéri Le Bouder
TopGit is a good idea, I don't think we should for its use (yet).
Libs: Should we provide .so when upstream only provide .a
Gonéri Le Bouder
I think we should not fight when upstreams don't want to deal with the ABI. We should provide a libpackageversion-dev package only. Such library are not widely used, that's why I think security binNMU are acceptable.
The advantages of shared objects over static libraries are really huge, and at some point it would be important to soify them. I plan to do that with that library at least. I'm just a bit concerned about if this is the time to do it, not about whether it should be done.
What about security problems with .a files in stable? it doesn't escalate very well, to need to do a lot of binNMUs in stable. In SID or testing it might be an option, but stable?
There is also the obvious security issues with only providing static libraries, in that if there is a security issue in the static library, all packages built against it will need to be rebuilt, this was the main reason I created shared libraries for plib, but could the risk be considered insignificant? After all they are only games libraries... (Mostly?)
Also I don't think creating shared libraries is much of an issue, as long as it's done properly, the easiest way obviously being to patch the build system directly, so as to create the shared libraries as upstream would, hacking them on top really isn't very good as it's likely to violate policy in other ways (i.e. the old plib package, not linked against dependencies). But obviously doing this is easier said than done with some build systems, and I agree there is still a lot of overhead/potential problems with patching things autotools build systems.
If there are only very few packages who depend on the library, it might work out. The more dependencies there are the more bigger headaches we get, both from binNMU requests and especially from a security point: If there is a problem in a static library you will have to update all build-depending packages. So where possible, upstream should definitely get educated on the topic and what it means to the users of their library. If upstream doesn't want to use basic considerations on compatibility issues propably they won't have too many people using their libraries anyway because it becomes a headache for the people using the library, too.
For the "bullet" case, its upstream author do not keep back-compatibility between releases. So binNMUs may cause working applications broken. In this situation, I think static-library-only is the best option.
I do not think we can keep all the different versions for a single library. Projects which want to use "bullet" should include everything needed in their-own tarball to prevent such compatibility issue.
"bullet" has much nice 3D demos, so it is worthy to be packaged even other projects may have their own "bullet".
In these types of cases, you could create shared libs with release type version (i.e. libbullet-<version>.so) to alleviate the problem with ABI breakages. Ogre uses this type of SO versioning.
What Andres Mejia said.
- Use Debhelper, avoid CDBS.
Explanation: Every maintainer knows how to use DebHelper, as it is the current de facto standard in Debian. CDBS and other packaging systems, including packaging from scratch, make a difficult entry barrier for new people in the group and for sponsors.
- Use a patching system, preferably quilt but dpatch is also acceptable.
- Explanation: If we don't modify the sources directly, we don't have to store all of them in the versioning system. Having individual patches for individual changes makes everything more clear. Using a patching system instead of relaying in SVN logs makes the package analysis independent of SVN. We won't make usage of the diff.gz files to store the changes to the programs.
- Exception: Some exceptional situatios can lead to an exception to this rule, for example autotools bootstrapping.
- Every modification to the orig file should be contained in the debian/ directory.
- Explanation: If we keep the changes confined to that directory, we can guarantee that the original sources won't be touched directly, and everyone in the group can see at a glance which part belongs to Debian and which belongs to upstream.
- Only the debian/ directory should be stored in the SVN system.
- Explanation: It makes it more clear to handle, download and work with.
Original tarballs should go to http://pkg-games.alioth.debian.org/tarballs/
- Explanation: It makes more sense having them stored in a directory than in SVN or a versioning system.
- You can achieve that by a command in the spirit of
scp vegastrike_0.4.3.debian1.orig.tar.gz alioth.debian.org:/home/groups/pkg-games/htdocs/tarballs
Some tips on how to use patches efficiently (Thanks Linas Žvirblis):
- Provide descriptive file names for your patches: 'fix-loading-libfoo-on-architecture-bar.patch' is a god name, '001.patch' is not;
- Make your patches stand-alone. Each patch should apply cleanly without depending on any other patch being applied;
- Avoid modifying the same file in multiple patches;
- If you absolutely need to create patches that depend on each other, specify that in the filenames: '00patchfoo-do-this.patch', '01patchfoo-do-that.patch' or similar;
- Do not include multiple unrelated modifications into a single patch;
- Patch your packages at build time. There is no need to ship a patch plus an already patched source. This only increases the size of the diff.
- Make sure patch is applied before anything else happens with your package. Make configure rule depend on the patch rule;
- Clean first, unpatch afterwards. Some files could have been modified during the build so unpatching may fail, unless you restore them. If simply makecleaning the sources does not restore their state, it may be a good idea to make backup copies, for example, in patch rule.