[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal for the tools policy



Hi,

Am Wednesday 20 September 2006 21:17 schrieb Miriam Ruiz:
> Hi,
>
> According to the oppinions written in
> http://wiki.debian.org/Games/ToolsDiscuss , and as I want to reach a
> consensus as soon as possible, I want to make the following proposal for
> the packages handled by the Games Team:
>
> 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.
>
> 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.
>
> Any suggestion? What do you all think?

Great!

For 2-4 I'd like to add an exception for autotools generated stuff, which imho 
is much more confusing/difficult to have in a patch system (at least in 
dpatch, haven't tried to do it with quilt yet) and is not really of any use 
in patch form (can't send it to upstream and needs to be regenerated for each 
new upstream release). Stuff that's not generated though (e.g. Makefile.am's) 
should stay in the patch system.

Something not yet mentioned is the archive layout:
a) just plain trunk/packagename
b) packages belonging together in their own subdirectory
(I personally would favour b) a little bit, since you know what other packages 
to touch when modifying one package, but a) also has its advantages like 
easier scripting and you can find out easier if a package is in svn by 
looking just at one directory).

Cheers,
   Stefan.

Attachment: pgpFPN0pAITKs.pgp
Description: PGP signature


Reply to: