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

Re: Build-dependency for rasmol: cbflib



Hi,

On Thu, Mar 27, 2008 at 07:01:10PM +0100, Teemu Ikonen wrote:
> >  > 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).

That's all nice, but doesn't really belong here.  Both debian-med and
debichem use the keep-debian-in-subversion approach, so if you want to
group-maintain your packages in one of these teams (and debichem would
invite you to maintain rasmol there), you'd have to adopt to the current
workflow, sorry.  

We could still discuss having debichem or debian-med as Maintainer and
you and some other interested people in Uploaders so we can at least
tackle bugs together etc., but not being to work together in the package
repository would be a downside.


Michael


Reply to: