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

Re: New upstream version of velvet contains debian/ dir



Hi Scott,

On Fri, Sep 07, 2012 at 01:25:30PM +0100, Scott Smith wrote:
> I wanted to be clear on what you're asking.

:-)
 
> We install everything on our cluster using Debian packages, and when packaging isn't done elsewhere we do it for internal use, and offer it to the public for use at their leisure from our apt repo.
> 
> For key bioinformatics software we re-package them specially so that all executables contain version numbers, and different versions result in different packages.  This is part of our reproducibility system, and may be of use to some, but certainly not all users.

Thanks for the explanation of your workflow.

> Are you telling me that we're doing the packaging incorrectly, or that we shouldn't make an apt repository available?

Neither of both.  I was talking about the upstream source you are
providing which per definition has nothing to do with any packaging (be
it for Debian or as RPM) at all.  Maintaining a copy of the debian/
packaging dir inside the source archive is for at least three main
reasons confusing:

  - The user (who downloads the upstream source) might assume this
    would be the official packaging stuff but it is not.
  - You forked the official packaging at some point in time and
    you are lacking intermediate packaging steps of several versions
    which are just Debian packages (and are available at
    snapshot.debian.org.
  - You are forcing the official Debian maintainer to take extra
    means to handle the incompatible packaging dir.

So please, whatever service you might provide as Debian packages -
please maintain the debian/ dir in a separate place outside the source
tarball which is distributed at your homepage[1].

So far for the hopefully more clarifying explanation.

Now for the ideas that came to my mind when reading your explanation of
your requirements:  We do not yet have a default way to handle different
versions of the very same program inside Debian but this issue comes up
from time to time on the Debian Science mailing list.  It might make
sense to bring this topic again.

In any case I would consider it very reasonable to maintain the
different versions of velvet in branches inside the Debian Med
repository.  IMHO it really can not harm if Debian Med users are aware
about those versions you consider worth putting into a specific
versioned Debian package.

So my suggestion would be the following:

  1. You might consider becoming a member of the Debian Med team -
     the procedure is described in our policy document[2]
  2. Decide what VCS might fit your needs best (I noticed that you
     are maintaining Velvet source code in Git - that would be fine
     as well.  Just let us know your preference.
  3. You maintain the Debian packaging directly inside the Debian
     Med repository and just ping us for an official upload (the
     process is called sponsoring.
  4. If you need some specific versioned Debian package with
     versioned binaries you simply create a branch.  (BTW, I have
     no experience with these things because there was no real need
     so far in my practice but as far as I know it is possible to
     let cdbs automatically create the proper debian/control file
     to safe your time.)
  5. If you want to provide inofficial packages which are for
     whatever reason not intended to be uploaded to the Debian
     mirror please use the following versioning scheme:

        <velvetversion>-0<yourdist>

     Example:  For Ubuntu packages <yourdist>=ubuntu

Hope this is clear enough - feel free to ask for more details if not.

> Thanks for any advice you have..

Thanks for your cooperation

        Andreas.

[1] http://www.ebi.ac.uk/~zerbino/velvet/
[2] http://debian-med.alioth.debian.org/docs/policy.html
 
> On Sep 7, 2012, at 12:52 PM, Andreas Tille <andreas@an3as.eu> wrote:
> 
> > Hi Scott,
> > 
> > when I downloaded thesource tarball of new upstream version of velvet I
> > noticed that it contains a debian/ directory.  This is usually a bad idea
> > and should not be done (feel free to ask for a detailed explanation why
> > and I spend some time to pick links and give more detailed reasons.)
> > 
> > It would be really great if you would drop this from your next source
> > release.  If you really like to maintain the debian/ directory I would
> > suggest you join the Debian Med team which maintains a lot of medical
> > and micro-biological software in its version control system.  We would
> > be really happy to see you in our team and you can trust on kind
> > guidance in case of some Debian related issues.  You can also influence
> > the soonish release of new versions if you ask for sponsoring your work
> > to official Debian mirrors.
> > 
> > Kind regards
> > 
> >       Andreas.
> > 
> > -- 
> > http://fam-tille.de
> 
> 
> --
> To UNSUBSCRIBE, email to debian-med-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] F616305F-C6BF-43EC-8659-909C1BFC4F19@genome.wustl.edu">http://lists.debian.org/[🔎] F616305F-C6BF-43EC-8659-909C1BFC4F19@genome.wustl.edu
> 
> 

-- 
http://fam-tille.de


Reply to: