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

Restricting citation information to single binary packages? (Was: Status bibref gatherer)



[Aaron, please read ahead about the question whether there are other publications
 for ncbi-tools]

Hi folks on Debian Science,

on the Debian Med list we had some discussoin about the handling of
ciatations.  As I wrote in last Debian Med bits[1] in paragraph 6. we
are currently doing heavy work to finalise what started in the beginnig
of 2010.  The goal is to move the biobliographic information which is
currently kept (hidden) in the Blends tasks files to debian/upstream
files which is also on the Debian Science todo list[2].

Thanks to Charles' UMeGaYa effort[3] we do have about 100 citations kept
into debian/upstream files which are gathered (not really dayly but we
are working on this) straight from package Vcs to make it very easy to
keep bibliographic information up to date.

Regarding the tasks pages of web sentinel I have some working code ready
to prefer the information from these files over the information inside
the tasks files which means, if there was some bibliographic information
found in the debian/upstream file (the information is moved to UDD[4]),
the Published-* fields for this package are ignored in the tasks file.
If no such information exists the Published-* fields are regarded as
usual.  This change is also reflected in the Blends doc[5].s

While checking the code which creates the tasks pages I'm quite busy to
copy information from tasks files to debian/upstream files and I'd
suggest you should do the same in case your are touching a package.
There is no need to remove the information from the tasks files
immediately because I tweaked some code into the tasks generating script
which outputs a list of equal valued fields which can be deleted via
script in one rush from the tasks files.

So far for the good news.  However, Michael Banck yesterday raised a
potentially weak point in this approach:

On Thu, Mar 29, 2012 at 05:37:51PM +0200, Andreas Tille wrote:
> On Thu, Mar 29, 2012 at 04:51:51PM +0200, Michael Banck wrote:
> > What if you want to have different publication data for different binary
> > packages, or exclude some binary packages from publication data?
> > 
> > Point in case would be openbabel, where the python bindings had a
> > dedicated publication, or possibly some libfoo-dev packages in a
> > development tasks, for which the main publication data might not be very
> > useful or applicable.
> 
> This is a good question where I do not have a good answer for.  By
> accident I stumbled upon this today in the case of blast2.

I admit I do not heavily care about some "potential" foo which might
exist, but as I said we have some practical case with the binary package
blast2 which is part of ncbi-tools6 source which builds several other
binary packages which do not make sense to carry the Blast citation(s).

Aaron, could you provide some bibliographic information for those
ncbi-tools which are not specifically describing blast?  This would be a
critical point to find a sane decision.

> For the moment we consider the publication data as a feature of an
> upstream source.

Could anybody please raise his opinion what might be the correct relation:

  source package   <->   publication
  binray package   <->   publication

This is a *very* critical question because as a consequence the whole
point in putting the information into debian/upstream depends on this.
IMHO it does not make sense to invent debian/<pkg>.upstream because
upstream information is about the source not the binary package.  So the
consequence of the answer of this question would possibly be to move
bibliographic information into binary package space and use
debian/[<pkg>].bibliography (or debian/[<pkg>].bib because in this case
we could even start using bibtex format).

So please think twice about your answer because it somehow would be a
quite big change (which I personally would be afraid about).

> Do you have any suggestion how to work around this?

My alternative suggestion would be to say:  Well, blast2 is an exception
and it is a general feature to have citations added to *all* binary
packages of one source (it's no bug but rather a feature!)

I'm experimenting with an additional value for the Reference field which
is called 'debian-package'.  If this field is set the bibliographic
information is only attached to this binary package.  For this sake I hope
Aaron can provide some reasonable citation which belongs to some other
binary package from ncbi-tools6.  If I find a reasonable way to handle
this I'm positive that the current approach is correct.

Any comment is more than welcome (rather *needed*) to make a sane
decision.

Kind regards

      Andreas.

[1] http://lists.debian.org/debian-devel-announce/2012/03/msg00009.html 
[2] http://wiki.debian.org/DebianScience/ProblemsToWorkOn
[3] http://wiki.debian.org/UpstreamMetadata
[4] http://wiki.debian.org/UltimateDebianDatabase
[5] http://blends.alioth.debian.org/blends/ch-sentinel.en.html#s-packageslist

-- 
http://fam-tille.de


Reply to: