Re: [RFR] templates://auctex/{auctex/templates}
David Kastrup wrote:
> Justin B Rye <jbr@edlug.org.uk> writes:
>> Ah! So where it all went wrong was when I asked way back near the
>> start of this thread:
>>
>> # I don't see how these can both be right. It (a) exists to allow
>> # previewing in Emacs but (b) doesn't need to suggest any emacsen?
>>
>> The answer should have been that (a) was wrong and that the package
>> description shouldn't mention Emacs at all (or if it did it should
>> at least mention LyX equally prominently). Is that right?
>
> No.
Sorry, my question must have had too many nots in it - the following
confirms my deduction that (a) was wrong:
> Again: the LaTeX style is useful all on its own. There are
> certainly workflows that involve neither Emacs or LyX. It can be used
> in any PostScript or PDF workflow involving LaTeX.
>
> Other packages depend on preview-latex-style, but preview-latex-style
> at best depends on LaTeX.
>
> The only recommendation/suggestion that I see is that people
> having installed _both_ Emacs and LaTeX should possibly get a
> suggestion to install AUCTeX.
In that case you probably won't be happy with the current proposed
package-description synopsis for p-l-s:
"http://lists.debian.org/debian-l10n-english/2007/11/msg00025.html";
Would you mind commenting on that?
(If you do that, you might as well ignore all the rest of this.)
>>> No. You are confusing your dependencies. AUCTeX requires
>>> preview-latex-style, not the other way round.
>>
>> That doesn't help somebody who sees p-l-s in the package-lists and
>> is persuaded to install it without realising it has any connection
>> to auctex.
>
> AUCTeX should depend on preview-latex-style. While it is
> theoretically possible to use AUCTeX without preview-latex
> functionality, as long as it is compiled in, not providing the
> requisites does not make sense. But that's about it.
That's not the issue. We have to consider the situation from the
point of view of a user who reads the p-l-s package description, is
interested, and does "apt-get install preview-latex-style" without
realising it has any connection to auctex. Is that user going to
get the functionality advertised in the package description?
Even if p-l-s is commonly used without auctex, a Suggests: may still
be appropriate - it would mean that auctex is related to p-l-s and
can perhaps enhance its usefulness, but that installing p-l-s without
auctex is perfectly reasonable. If that's overstating the strength
of the connection, then fine, but it's *not* a question of absolute
dependencies.
>> Yup, sounds like a problem. How should we fix those docs (starting
>> with the package description) to ensure that they don't leave people
>> arguing against you?
>
> By using the docs I wrote.
Could you be more specific? Maybe you could comment on the RFR?
>> I was talking about /usr/share/doc/preview-latex-style/README.gz:
>>
>> # While the primary focus of the package has been the support of editing
>> # in Emacs buffers augmented with preview images, its possible uses are
>> # not limited to that.
>>
>> That makes it exactly the sort of "primarily but not exclusively"
>> that I'd expect to see expressed by a Suggests: dependency (or
>> indeed a Recommends:).
>
> Again, you are trying to put the cart before the horse. The
> suggestion dependency is that Emacs+latex should lead to the
> recommendation AUCTeX, but not the other way round.
The other way round would mean that auctex should have dependencies
on emacs+latex. In fact it already does. But that doesn't help
somebody who's looking at preview-latex-style in the archives.
>> The explanation's simple; I didn't read that file. In fact I still
>> can't find that file. What package is it in?
>
> The source tarball. There is a life before Debian packaging.
Are you really saying that users trying to find the answer to the
question "what is the basic point of this package?" should "Read The
Fine Source"?
>> I'm saying that users have to be able to trust the docs to be right,
>> and it was reading the docs that led me into arguing with you. We
>> badly need some input into the process of improving the package
>> description from the people who understand the package.
>
> The input is there in the source tarball. If you refuse the read the
> upstream material, there is nothing upstream can do to provide the
> "badly needed" input.
"Refuse"? How are users going to *know* there's material elsewhere
that overrides the documentation packaged as the official upstream
README.gz? Are you sure the Debian auctex maintainers know? The
README.Debian.gz just says to read the README.gz...
> It is there. Use it.
Now that I know there's a README more authoritative than the one in
the binary package, I have the option of hunting it down. But are
you planning to modify the README.gz that told me p-l-s was
primarily designed for use with emacs?
>> The functionality advertised by the package description should be
>> available to people who think "that package sounds good, I'll
>> install it". If in reality that functionality requires extra
>> packages to be installed (such as emacs, or auctex, or lyx) then
>> it's the job of the text and/or dependencies to make that clear.
>
> The package requires LaTeX, and that is it.
The headline functionality advertised in the package description is
editor-embedded previewing. Will users get that with nano, or
should we change the dependencies and/or description?
--
JBR
Ankh kak! (Ancient Egyptian blessing)
Reply to: