Re: Packaging tools (was Re: tarballs - why in SVN?)
Miriam Ruiz wrote:
> Me too, I totally agree with you. I think we should try to reach a consensus
> on the basic guidelines to try to follow in all the packages, concerning at
> least use or not of a patching system (dpatch) and the packaging helper to use
> (I see that no decision has been reached yet about whether to use Debhelper or
> CDBS.
I vote for 'debhelper'. CDBS is considered Bad Idea (tm) by many Debian
Developers, and I have seen people claiming that they will refuse to
sponsor CDBS packages. Trying to enforce CDBS will only scare people away.
I personally have little experience with CDBS, so I cannot comment on it
much. 'debhelper' simply works well for me.
> I don't know how to use CDBS and have usually avoided to use Dpatch, so I
> cannot talk about their pros and cons. What I see is that those tools mean a
> higher entry barrier for many people packaging, but that's something that can
> be acceptable if the advantages are relevant.
Why 'dpatch'? I consider 'quilt' a far superior solution. Creating a
patch in 'quilt' is as easy as:
quilt new patch-name.patch
quilt edit some-file
quilt edit some-other-file
quilt refresh
Done. You now have a shiny new patch.
> Any ideas?
Instead of trying to persuade people to use patch management systems, I
will provide some tips on how to use them efficiently:
* 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.
Reply to: