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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120221143848.ge14...@an3as.eu