Re: References, registrations
Andreas Tille wrote:
> On Sun, Aug 23, 2009 at 09:48:59PM +0200, Steffen Moeller wrote:
[..]
>> The page has not yet updated itself, so I cannot be too critical myself about it, though I
>> knew autodock to have a fresh paper out, which is a nice use case for having both the
>> citation and the registration info shown.
>
> Let's wait for tomorrow. ;-)
(thumbs pressed, fingers crossed, ..)
>> For the registration I have added a "Publication-URL" entry, which would need to span
>> around the title (which is the way pubmed.org is shown them) or around the whole block
>> (ugly?). This way this should work for all kinds of Blends and may also comprise dimploma
>> theses or technical notes that one finds at many universities.
>
> I'll add this nice idea soon.
Nice to hear you like it.
[...]
>> * Would there be a sufficiently easy away to directly link to the developer's page like
>> http://packages.qa.debian.org/p/packagename.html
>
> We have a link to packages.debian.org. We surely can add also a link to
> the developer oriented page - I'm just afraid that we might overload the
> page - but in principle there is no problem in doing so.
It is a bit awkward since the package's initial letter is part of the URL, but this "all
on one page" kind of link I very much prefer over the current one. The regular users
should rather investigate upstream's page and the README.Debian file of the package they
install. They don't need to learn about the dependencies and such, IMHO. Either they need
the software or they don't.
>> * We need to get a paper out on this all - say when the freeze is spoken
>> out loudly? It is then not unlikely to appear kind of in sync with the release.
>
> What do you mean "we need to get a paper". I just updated the blends
> doc today (and I just guessed you might have read this before doing
> the change).
I meant something scientifically citable for everybody's "Methods" section.
"Bioinformatics" (kind of a well-respected default journal, impact factor about 4.2) for
instance seems likely IM(and Andreas H.'s)HOs to take us. I'd want to discuss details on
some platform that is not googled or archived, though.
>> * [CS]ould we link to the man pages of the respective program? Ubuntu has
>> http://manpages.ubuntu.com/manpages/intrepid/man1/autodock4.1.html
>> and I would not mind seeing references to their site ... but I don't really
>> know how to do this.
>
> Hmmm, I would prefer to stay inside debian.org domain just for the
> sake of consistency. Moreover I have few means to verify that this
> page exists and remains to exist.
It is also more of a job for the regular Debian page displaying the package. Sargis had
impressed/surprised me with the Ubuntu page. And I liked it.
>> Again, many thanks and greetings
>
> Once we are at the topic of web tools: I'm really waiting for an answer
> from you why you think that mgltools fit in your categories Friends /
> Enhances-By / ... for autodocktools
No, I don't think that mgltools are enhanced by autodocktools. I was only looking for some
indication that says "I am interested in the mgltools packages because I am interested in
autodocktools, but please don't list all the mgltools packages as interesting packages in
their own right, unless you find a bug in them."
> but you refuse to add the Enhances
> field to the control file of mgltools-*.
I would not say "refuse", it only depends on what you intend to bribe me with. :o) I think
it is wrong. Our misunderstanding may result from differences between the semantics of
"enhances" and may sole motivation that I summarised above.
Autodocktools depends on the mgltools packages (directly and indirectly). The only
exceptions are mgltools-PMV and mgltools-Vision, which may stand on their own, the latter
is not even used by autodocktools. Vision is a workflow tool. You can automate what you'd
manually do with autodocktools. Here, we clearly have a case for the "Enhances", Vision
does enhance autodocktools. To me A enhances B, i.e. A improves on B iff A is optional to
B and when A has a functionality that is not already in B. However, in the case for the
mgltools, with the exception of -vision, for all A in mgltools-* : A part-of
autodocktools. And with A being part of autodocktools, the functionality of A is already
part of the functionality of autodocktools, hence nothing of A can enhance autodocktools.
One may argue that autodocktools enhances PMV. I would not fight against that. But we have
that dependency already. While formally with respect to input/output realms, Vision has
the capability to substitute autodocktools, but not conversely, one may speak of vision to
enhance autodock. But practically speaking, the GUI is completely different, it is
completely different way of thought and consequently also the userbase is mostly disjunct.
With vision enhancing autodock, we want to stress the importance of vision for us. This
would be fine with me (in the case of vision). But all the other packages to which you
desire to add "enhances" don't enhance autodocktools, they are just part of it. And I want
to hide them, not stress their importance.
> Having no answer to this
> problem which I clearly fail to understand blocks somehow proceeding on
> the Enhances topic. IMHO, using Enhances of the packages control field
> is the perfect way to go in such cases.
I think that (as a start at least) we should leave the debian/control fields for the
reasons that Debian wanted them initially. Or not use them at all until we know what we want.
To learn what we want, and to help communication between ours, I suggest to edit the
blends' tasks file with the information that we want to interpret. Should we then find,
that we use a term in the exact same way that Debian has already thought about using some
(not necessarily syntactially identical) term or combination of terms, then, well, sure,
let us use the Debian one(s) and transfer the information into debian/control or
elsewhere. I don't think we are there, yet.
Many greetings
Steffen
Reply to: