Differences between revisions 43 and 44
Revision 43 as of 2008-06-09 10:50:17
Size: 3858
Editor: ?goneri
Comment:
Revision 44 as of 2008-06-09 13:54:52
Size: 4786
Editor: BradleySmith
Comment:
Deletions are marked like this. Additions are marked like this.
Line 28: Line 28:

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.

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 [#bottom conclusions] (no pun intended).

Old discutions

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.

Miriam Ruiz

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.

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.

Conclusions

  1. 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.

  2. 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.
  3. 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.
  4. Only the debian/ directory should be stored in the SVN system.
    • Explanation: It makes it more clear to handle, download and work with.
  5. 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

  1. TODO

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.