Re: Turning debian/upstream into BibTeX (Was: Tasks pages (close to) fixed; Bibref does not seem to be updated automatically)
On Tue, Feb 21, 2012 at 08:56:13AM -0500, Yaroslav Halchenko wrote:
> > Published-Authors: Alois Schlögl, Clemens Brunner
> > Published-DOI: 10.1109/MC.2008.407
> > Published-In: Computer, 41(10): 44-50
> > Published-Title: BioSig: A Free and Open Source Software Library for BCI Research
> > Published-URL: http://pub.ist.ac.at/~schloegl/publications/Schloegl2007_BCI_Software.pdf
> > Published-Year: 2008
> > Published-Authors: Some other Author
> > Published-Title: Some stupid title
> > ...
> > value text NOT NULL,
> > rank int NOT NULL,
> > PRIMARY KEY (package,key,rank)
> > );
> > >...<
> > In short: If we really want to support multiple references we need to
> > clarify the use cases and the implementation details first. I'm
> > personally not really convinced that we could not go with one major
> > reference per package and whether the trouble we need to deal with is
> > worth the effort for some exceptions.
>
> What about adding an explicit 'Key' field, e.g.
>
> Published-Key: IntroPaper
This might be a working idea - at least in principle. We can drop the
"Published-" prefix which was used in tasks pages but this system should
be replaced and I would like to focus on debian/upstream issues only.
In this scope it woul rather be:
Reference-Key
My problem by using this is hackish in the same way because we are
claiming that this is an information given by upstream which is
certainly not the case but rather Debian internal metadata.
> or may be even (I guess uglier -- just throwing ideas) using the key
> within field name:
>
> Published-IntroPaper-Authors:
> ...
>
> Published-Method-Authors:
>
> Then bib entry could get an entry code as 'Package:Key'
Same here for non-upstream data. But we might come to these details
once we decided about the storage which also needs an unique way of
identification so the bibtex key might come for free from this decision.
> For the task pages, you can indeed take the first or the last entry
I would like to drop the injection of references inside the tasks pages
at all in favour of debian/upstream. The only thinkable use for such
fields would be if we inject prospective packages with no start of
packaging in any Vcs. I would like to argue that if the interest in a
package is that low that we would not even inject some initial data into
Vcs we do not even need publication data attached to it.
BTW, I also started wondering whether I could somehow drain the
Pkg-Description from Vcs once a package is there. When we fetch
debian/upstream from Vcs why not also fetching data from debian/control
which might be there. I'll put this on my todo list.
> > > ;-)
> > BTW, every developer is free to mention debian/upstream in debian/docs
> > for the moment - we just missed to do this.
>
> I should start introducing it to my packages following
> http://wiki.debian.org/UpstreamMetadata
> specs
Yes. And not only you. :-)
> > fine. The only thing we should decide when finding a name would be
> > whether we want to restrict it explicitely to bibliography or whether
> > we rather stick to a more generic "upstream" name which enables more
> > flexibility in case we need to handle some other upstream data.
>
> rright -- what other use cases do you see behind such tools?
tasks/bio has:
Depends: rasmol
Registration: http://www.rasmol.org/register.shtml
Depends: autodock
Registration: http://autodock.scripps.edu/downloads/autodock-registration
We might also consider "Donations" or something like this. This is
surely upstream data and we could respect this on the tasks pages (and
for Registration we are actually doing this currently).
The thing is: We are trying to make Debian more attractive for upstream
so we are just showing them that we can be helpful and work in their
interest. For instance when distributing packages inside Debian we are
shamelessly bypassing upstreams means to track their users. I could
imagine a dh_registration which parses debian/upstream to create a
debconf notice to ask the user for registration. I do NOT say that I
will be the person who writes such things nor that I would actively
support this. However, there might be reasons to keep things more
flexible and not to restrict this to references. I assume we will have
more clever ideas for other use cases once we are using the system more
actively.
> > > IIRC I have looked for such a place and there were no suitable one (I
> > > could be wrong), so in that preliminary debian-bibliography
> > > package we placed /usr/share/bib/debian.bib with the intent to seek
> > > adding /usr/share/bib into default BIBINPUTS.
>
> > I do not consider /usr/share as the right place to put autogenerated
> > data and the method I described is autogenerated.
>
> yeap -- I got that aspect ;-) But if we would be to hunt adjusting
> default BIBINPUTS we could extend it with /var location as well.... or
> we could just symlink it under /usr/share/bib -- it seems to be not
> uncommon to symlink /var stuff under /usr
Ahh, OK. Fine.
> once again -- that one was intended to be complimentary to 'software'
> bibliography
OK. Thanks for clarification.
> as for "frozen version" -- we indeed might like to generate the ultimate
> .bib file through harvesting full archive
To say this clearly: I'm not fully sure what might be the best solution
and it might make sense to provide a fixed BibTeX file after Debian
freeze. However, for the moment I prefer the aspect of higher
flexibility of an autogenerated list for the following reasons:
1. The frozen list will probably a subset of the dynamic list
2. People might use backports / manually builded from VCS and
are simply lacking references inside static list which are
easily available in the dynamic list
Do you see any competing pros for a static list?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: