Re: Re^6: Debian Metadata Proposal -- draft rev.1.4
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> APH> Putting the same info, shadowed in multiple places, is exactly what
> APH> dhelp does.
>
> ??? That#s wrong.
You must not understand my terminology. The fact that you are
constructing a database out of the metadata, in the current dhelp,
means that you are "shadowing", or "keeping another copy" of the
metadata itself. This leads to bugs and problems. It's a fact of
software design.
My dream is to have a single fast-access method of accessing metadata
that works for *all* display systems, but that might be a pipe dream.
Read that as, "I'm not planning on having it in the next major release
of install-docs".
> APH> I propose to eliminate that and adopt a central document
> APH> store, rather than having display systems read docreg files.
>
> No, we#ve discussed this already. It should be possible to use dhelp on a
> non Debian system. And I need special organized databases. You can add an
> API to doc-base, no question. But (a) I don#t need it and (b) this would
> be a doc-base project and shouldn#t be part of the file format standard.
Sure. Of course, you realize the file format standard is just a
chapter of the broader Debian Metadata standard. You seem a bit
confused on this point.
> APH> crucial requirement for debugging, and dhelp contains a number of
> APH> critical bugs because
>
> Nonsense, there#s no real bug in dhelp. Please tell me the number of the
> bug report.
Bug#21361. If I did a security audit on dhelp, I'm sure I could find
a number of overflow conditions and bugs in the system could be
triggered by malicious dhelp files. Since dhelp_parse -r will readily
gobble these, and since root usually runs this, the current situation
is a little troubling.
> APH> (a) it's got it's own document store, which
> APH> isn't well debugged, and
>
> What an argument against a file format :(! Are you kidding?
No, an argument against data shadowing implemented in each and every
display system. Again, it's worrying but I don't think we're going to
solve it this time around, but you should recognize the flaws.
> APH> We propose to resolve relative links against a "path" of
> APH> /usr/share/doc:/usr/doc:http://www.debian.org/doc .
>
> That#s a very bad solution. This is (a) very slow (200% slower)
Granted.
> and (b)
> how should I resolve something against http://www.debian.org/doc? And in
> Germany and a lot of other countries a Internet connection is very
> expensive.
You're totally befuddled on this point, but it's understandable. I'll
summarize my position on this issue in the next post.
> Ok connections between translations won#t work. But this is not a real
> problem. And as mentioned yesterday, there#re other cases where we will
> have the same problems.
> Maybe it#s not a good idea, to use the filename as identifier. Our old
> solution (doc-base) hasn#t got this problem.
Very true. But it uses a "surrogate key" system and has no way to
resolve namespace conflicts. Each package should have its own name
space; we already have gloabally unique package names.
--
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: