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

Re: Build-dependency for rasmol: cbflib

On Wed, 26 Mar 2008, Teemu Ikonen wrote:

Rasmol upstream has now released version, 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


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:   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.

Please teach upstream to distribute proper tarballs without CVS

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

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

[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

Reply to: