[Debichem-devel] Build-dependency for rasmol: cbflib

[Teemu Ikonen]

On Wed, Mar 26, 2008 at 2:50 PM, Andreas Tille <tillea at rki.de> wrote:
> On Wed, 26 Mar 2008, Teemu Ikonen wrote:
>  If you maintain your packages in a VCS please add propper tags to
>  the control file.  My wild guess is, that they should look like
>
>    Vcs-Browser: http://git.debian.org/git/collab-maint/cbflib.git
>    Vcs-Git: git://git.debian.org/git/collab-maint/cbflib.git
>
>  but please verify this - I have no experience with git.  Please
>  add proper lines to debian/control.  Moreover there are two
>  Build-Depends missing: m4, gfortran

Oops, indeed these were missing, I've now added the Vcs fields to both
rasmol and cbflib and fixed the build-deps. I also forgot to close
some bugs in the rasmol changelog. The packages have been updated to
fix these issues.

>  > Team maintenance for these packages is ok, if the team in question
>  > wants to work with git.
>  For the package in question the DebiChem team (in CC) comes into
>  mind as well.  Moreover team maintenance does not necessarily
>  requires the use of a VCS.  It is using a common list as Maintainer
>  and some Uploaders in the first place.

Again, I have nothing against changing the Maintainer field to e.g.
DebiChem in these packages, if this does not impose a workflow I
consider sub-optimal.

Let me expand a bit on how I think version control should be used in
packaging: When I check out a packaging branch from a VCS repository,
the result should be a working tree containing the whole upstream
source plus debian files and modifications. One should be able to
build binaries right away with debian/rules binary, and a source
package with dpkg-source, given an orig.tar.gz. With git and
pristine-tar, the orig.tar can be very easily generated from the
repository with close to zero additional space cost.

What kind of a source package is then generated from the VCS sources
is a somewhat unrelated issue. The traditional diff.gz with all the
changes applied to the source is nice for simple packages with only
small changes. Having quilt / dpatch patch stacks inside the diff is
ugly and needs extra build-depends, but allows for separation of
patches for different functionality, which is nice. I think a good
compromise would be the wig and pen source package format (
http://www.dpkg.org/dpkg/NewSourceFormat ) with support for unpacking
and packing the source with applying and generating patch sets
automatically in dpkg-source, but its implementation is apparently
prevented by some strange dpkg politics.

A source package format containing a VCS repository is too much crack
for my taste, and imposes a tool preference to anyone working with the
package. I recently made scripts which flatten an arbitrary number of
feature branches in a VCS (git in this case) to series of patches, so
generating source packages in e.g. quilt format out of VCS
repositories is possible in principle, it just needs tools which are
not standard or well known (or in this case even published).

>    2. On the other hand an individuum should recognize that staying
>       in a group has advantages and that it is sometimes not possible
>       to set preasure on the group like:  I will join your team if
>       you are using bzr, darcs, ... (include your prefered VCS here)
>       because this would keep the group busy in handling different
>       VCS (believe me, git will not stay the latest and greatest)
>       and developing tools that add great value to maintenance like
>       our developer page[2] will become more and more complex for
>       less profit.

Just a note, distributed VCS's are converging fast and converting from
one repository format to another is already easy. Probably (hopefully)
in the future this conversion will be made automatically, so that
different programs can push and fetch from each others repositories
transparently.

Regarding your developer page, writing a small post-commit /
post-update script which updates the "recent activity" section in the
Debian Med page should be possible for any VCS. This hook should then
be installed on every VCS repository on alioth which is part of Debian
Med.

>   - What is the extra value that git adds to the Debian-Med project?

The same as in every other distributed VCS, disconnected operation and
very easy branching and merging.

>   - Would git2svn be an acceptable alternative / compromise to
>     be able to cooperate?

Two-way syncing between SVN and most other distributed VCS is possible
(I've tried it with bzr and git). The problem here is not really
subversion, but svn-buildpackage, which encourages storing only the
debian dir. I suppose it would be theoretically possible to write
scripts which synchronize this kind of partial branches with a branch
containing the full source and applies patches etc., but this would be
a lot of work for an application that is Debian specific and IMO not a
recommended way to maintain packages in a VCS anyway. Disk is cheaper
than peoples time.

>   - Would you volunteer to convert the existing SVN completely
>     to git and convince others to use git from a certain point
>     in time?

Even in team maintenance there are people who work more on some
packages than others and these persons should decide for themselves
what tools they want to use.

Although I don't have that much interest in Debian Med or DebiChem, or
the tools you have, it would not hurt to make the projects more VCS
agnostic.

>  [1] http://lists.debian.org/debian-med/2008/03/msg00150.html
>  [2] http://debian-med.alioth.debian.org/
>  [3] http://debian-med.alioth.debian.org/docs/policy.html

Best,

Teemu