Re: Packaging tools (was Re: tarballs - why in SVN?)
On 15/08/06, Linas Žvirblis <0x0007@gmail.com> wrote:
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.
Since mail discutions are not going to reach a consensus because they
are hard to be accounted, I have created the page
Games/ToolsDiscuss[1] which should gather all the oppinions and we
should decide later what to do. I have filled in my answers. Please
follow the proposed format, or reorganise in a better way.
mainly my choices are
+debhelper
+cdbs (experiment)
+dpatch (where source is not in SVN)
*quilt (never used it)
> 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
dpatch-edit-patch patch-name.dpatch
edit files
exit
Done.
* 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;
This is a real bitch now for me in glest. I am more and more inclined
to patch the Jamfile via the diff.gz to add the clean rule, because
that Jamfile should always have the clean rule... and the building of
the editor should be disabled because the source is not present in the
released tarball.
* 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.
Thanks for the hints.
Maybe people in favour of of tools like cdbs or quilt should present
them in an IRC training session. This way we can take an informed
choice on the usage of a tool.
[1] http://wiki.debian.org/Games/ToolsDiscuss
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: