Re: Build-dependency for rasmol: cbflib
On Wed, 26 Mar 2008, Teemu Ikonen wrote:
Rasmol upstream has now released version 2.7.4.2, which also contains
my GTK patches. I've made new packages of rasmol and the new
build-dependency cbflib. The source packages are at
http://esko.osmas.info/~tmx/cbflib/ and
http://esko.osmas.info/~tmx/rasmol/
Great!
I also changed the version control system for these packages to git,
and joined the Debian collab-maint group at alioth, the repositories
are accessible at http://git.debian.org/
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
If you try to use pbuilder to build the package it fails without
these build depends. Furthermore lintian throws an info notice:
I: cbflib source: source-contains-cvs-control-dir include/CVS
N:
N: The upstream source contains a CVS directory. It was most likely
N: included by accident since CVS directories usually don't belong in
N: releases. When packaging a CVS snapshot, export from CVS rather than
N: use a checkout. If an upstream release tarball contains CVS
N: directories, you usually should report this as a bug to upstream.
N:
Please teach upstream to distribute proper tarballs without CVS
directory.
So far for the packaging itself. For other readers I would like to
add the hint that IMHO the library should be packaged as pair of
lib/libdevel package but we might leave this for a later version of
the package if somebody volunteers to fix the build system regarding
this.
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.
Regarding the Debian-Med team we just had the git issue arising
last week[1]. The issue has two sides:
1. We - the Debian-Med team - does not really want to exclude
people just because of some VCS preferences, we are less
people enough and need every helping hand.
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.
So I'm not against git, but I'm against adding just another VCS if
there are no clear reasons for this specified (I do not accept a
"personal preference" as a reason).
- What is the extra value that git adds to the Debian-Med project?
- Are you volunteering to enhance the group policy[3] to explain
how to use git?
- Are you volunteering to add git parsing code to the web tools
we have developed?
- Would git2svn be an acceptable alternative / compromise to
be able to cooperate?
- Would you volunteer to convert the existing SVN completely
to git and convince others to use git from a certain point
in time?
These questions are not particularly targetting at Teemu, but we
will have to deal with these sooner or later. So we should be
prepared to have a clear opinion how to proceed in the future
because I see no chance that the number of popular VCS will
decrease.
[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
--
http://fam-tille.de
Reply to: