[Pkg-crosswire-devel] Revision control and packaging methods Re: about future packaging

[Дмитрий Ледков]

Daniel Glassey wrote:
> On Sat, Jan 24, 2009 at 3:55 AM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
>> Дмитрий Ледков wrote:
>>
>>> 1) What revision control system are we going to use? git, bzr or svn?
>>> ps I can help setup bzr or git structure to manage our packages. And
>>> provide guide/tutorial on how to use them for packaging.
> 
> Thanks, that will be a massive help :)

Is there a wiki or static pages on Alioth? Or shall I use
wiki.debian.org for that?

> 
>> Whatever Daniel decides, since we are using his existing packages as a
>> starting point :)  Ubuntu is heading towards bzr for stuff hosted at
>> launchpad.net, but I'm less sure what Debian as a whole is doing in this
>> regard, or if there is even an overall Debian tendency.
> 
> I'd say whatever the group decides. I'd be happy with any of the DVCS
> git, hg, or bzr since all of them can be used and are used on alioth.
> A very _very_ mild pref towards git because it's the one I'm most
> familiar with, but I haven't used it with packaging. I'd rather not
> use svn when there is an option of a DVCS.
> 
> So my votes are:
>        bzr   +1
>        git   +1.01
>        hg   +1
>        svn   -10
>        other 0
> 
> Has anyone got strong preferences or any reason not to pick whichever
> of bzr and git people here are most familiar with?
> 

With git-buildpackage you have upstream branch (one commit per tarball)
and master branch (debian packaging), git-buildpackage helps you to
merge new upstream releases clean way (no need to do anything), it also
can generate debian changelog from commit messages, so that a team can
just merge debian packaging and once ready generate changelog.

With bzr-buildpackage you can do above setup, or you can keep debian
packaging on it's own (svn-style packaging) and "merge" it into the
build directory at buildtime.

Both support debuild, pdebuilder, cowbuilder and what not =D
(customisoble per repo, per branch, per developer)

Git-buildpackage has support for pristine-tar. If enable, on upstream
tarball import it generates small binary delta, which is stored on it's
own in pristine-tar branch. Then at buildtime (automagically) a
byte-to-byte identical tarball to upstream version is generated with
matching checksums. Quite cool, but I got burned with this once =D Plus
a working watch file is much better anyways.

Both have it's unique features and both can do a top notch job. Bzr in
Ubuntu/Debian official repos is a bit dated (for ubuntu there is a semi
official PPA, Debian will have to rebuild the packages from there). Git
is up to date across both (experimental/jaunty, and I have git and
git-buildpackage from experimental in my PPA).

So it's really what tool most people are familiar with. Alioth supports
both.


>>> 2) CDBS
>>>
>>> Packages I've looked at (libsword-dev and gnomesword) both use CDBS is
>>> it OK if we continue using CDBS for all packages we manage?
>> I doubt it, since the current Debian and Ubuntu packages of sword use
>> quilt!  The general rule is to use whatever patch system the current
>> package is using.
> 
> quilt is the patch system. CDBS is the packaging scripting system.
> I'd like to stay with CDBS and use whatever patch system works best
> for the patches we have and the DVCS we use.
> 
>>> 3) Tarball inside tarball
>>>
>>> What was the point? there is no gain size wise, but upstream checksums
>>> are lost. Can we stop doing this? (looking previous two packages).
>> That's one for Daniel, I think??  Which specific source packages are you
>> referring to here?
> 
> I originally changed to that because it worked with my workflow at the
> time - drop test tarball in and rebuild. But I'm really not wedded to
> it and just want whatever system everyone can use.
> 

Cool. Using DVCS similar can be achieved. Branch, import-any-tarball,
build. But this time around upstream checksums will be preserved even
for experimental/local builds.

--
With regards

Dmitrijs Ledkovs.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-crosswire-devel/attachments/20090124/81fb875c/attachment.sig>