Differences between revisions 10 and 11
Revision 10 as of 2006-08-16 11:44:42
Size: 4842
Editor: ?goneri
Comment:
Revision 11 as of 2006-08-16 11:53:50
Size: 5084
Editor: ?goneri
Comment:
Deletions are marked like this. Additions are marked like this.
Line 85: Line 85:
== Gonéri Le Bouder ==
IMO, a source package must be readable out of the box. I like to have an overview of the change that the packager did by looking in the debian/patches directory. With quilt this can by done without a lot of pains.

This page is a discution place for the choices of the tools used in the Debian Games Team

Please add your answers, reasons and name for each question

Should we use debhelper? Why? Any exceptions? Did you used it before (which package)?

EddyPetrisor

Yes. Ubiquity, largely accepted, does the right thing. No. Yes (oolite, aspell-ro - unofficial).

MiriamRuiz

Yes, I think Debhelper is so commonly used that most of the maintainers know how to handle it. It provides so many pros that I'm totally for it.

Should we use cdbs? Why? Any exceptions? Did you used it before?

Gonéri Le Bouder

I tried to use CDBS on some packages from the SVN. For me the major issues are:

  • Pro: Useful to keep package clean but only if the build process is very standard
  • Con: no consensu in the team
  • Con: difficulty for upload. Alexander is not a fan of CDBS
  • Con: the great majority of games don't have a standard build system
  • Con: misterious issues hard to understand

I agree with a "no cdbs" rule in the team. In this case i've to clean up ri-li and libenet.

EddyPetrisor

I always admired the speed of package creation in Gentoo. The main reason behind the success and speed is the fact they use rules for classes of applications (gtk building rules, qt building rules, autotoolized building rules, etc.) and inheritance. This way they can reduce the amount of work needed per package if it can be included in a more generic class, which can happen most times, and they diverge only as much as needed. CDBS tries to do the same thing for debian packages. Thus I say we should give it a try for a couple of packages.

I never used cdbs before.

MiriamRuiz

I've never used it. The problems I find with it are mainly:

  • As many people are not familiar with it, requiring it for handling our packages can become an important entry barrier for joining the group.
  • It's very difficult to know what the system actually does inside, as it handles everything automagically.
  • I've tried to make minor changes, like adding -pg to CFLAGS, and was totally unable to find how to do it. If we decided to use it, we would probably need to make a fast course on it, or something like that.
  • It makes it quite difficult to find sponsors for the packages.

I'd prefer to avoid its usage.

StefanPotyra

Used it once for a python module, but I neither like it very much, nor have I very good knowledge about it.

  • Pro: Straight forward packages don't need much commands in debian/rules. Also it's a very powerful tool (see Eddy's description).
  • Con: It imho contains much black magic. It deludes that you don't need to know about its internals since it does good work for simple packages OOTB. But once you need to add some non straight forward customization to a package, you need quite good understanding of cdbs internals to get it right.

Should we use dpatch? Why? Any exceptions? Did you used it before?

EddyPetrisor

Yes, where the full source is not in SVN, but only the debian directory. Dpatch fits when only the debian specific part is kept in SVN because there is no ghost (only bits and pieces where needed) copy of the modifications. Should not be used where full source is in SVN. I used it in glest and other packages which I modified which were already using dpatch.

MiriamRuiz

I've used it before. I think using a patching system makes it a bit more confusing to analyze and the package, but it makes the packaging system more compact so only the debian/ directory would have to be uploaded. If we decided to use it, we should write some basic guidelines on how to make and handle the patches.

Gonéri Le Bouder

dpatch is the worst patch managing system after plain source.

Should we use quilt? Why? Any exceptions? Did you used it before?

EddyPetrisor

I heard is a better solution than dpatch when many patches are used in a package. I don't have any strong feelings either way, but I never used it.

Gonéri Le Bouder

Currently I use simple-patchsys.mk and i'm going to switch to quilt. I'm ok for a "quilt only" rule.

MiriamRuiz

I've never used quilt but I heard very nice things about it. If we decided for a patching system, I think we should use only one of them, and probably quilt is better than dpatch.

Should we use plain diff.gz files? Why? Any exceptions?

MiriamRuiz

As SVN handles the incremental differences in the uploads, it seems to make unneccesary the usage of a patch system, so modifying plain upstream files might be an option.

StefanPotyra

I second Miry. I just don't see much benefits of a patch system since we already use svn.

Gonéri Le Bouder

IMO, a source package must be readable out of the box. I like to have an overview of the change that the packager did by looking in the debian/patches directory. With quilt this can by done without a lot of pains.

Conclusions

Will be filled later