[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: future of dhelp



<daniel.nouri@con-fuse.org> writes:

> Is the doc-base files' format likely to change?

Yes.  Inevitable that it would change in fact.  It will always be an
RFC822 style format though (field: value).  I could do versioning on
the file format such that it can convert from file version 2 to file
version 1, as necessary.

> > Anyhow, this hook mechanism would mean that doc-base doesn't have to
> > know about dhelp or anything -- it just triggers the hooks and that
> > dhelp stuff is properly delegated out.

> >From what I understand, doc-base itself is currently being
> notified whenever a package installs or removes documents
> from the system. (At least that should be the case.) Am
> I right?

Yes.  To register a file at all, you must call 'install-docs -i ...'.

> If that is the case, I agree with you. However, I lack of
> ideas there... Will dhelp register itself with some script
> (hook) upon installation - so that it will be notified by
> doc-base without doc-base actually knowing that there is
> a dhelp?

Yes.  That's easy enough.  Here's a pass.

I provide a /usr/lib/doc-base/hooks directory.  Each file in there
should be an executable (script or compiled program) that takes a few
different first arguments (install, remove, version, possibly
'update').

If called as "/usr/lib/doc-base/hooks/program version" the program
returns an integer, what version do I understand.

If called as "/usr/lib/doc-base/hooks/program
{install,remove,upgrade}" it will accept one or more doc-base file in
the format that it understands in stdin (we'll have to figure out a
file separator for separate doc-base files passed all at once).

How does this simple first-cut sound?

> A further point would be my ambition to code dhelp fully in
> Python. 

I indend to stick with Perl for doc-base -- it's what I know.  It
shouldn't matter, though.

-- 
...Adam Di Carlo...<adam@onshored.com>.......<URL:http://www.onshored.com/>



Reply to: