Re: future of dhelp
> > > 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?
Some ideas that I'd like to be shared and weighed out by
you:
If we decide to ask the program for version compatibility,
then we need to at least back our new file versions
through debian package version dependencies. For example,
dhelp in the current stable branch does not support version
querying at all. Or some new package system decides to
support only from version 2 upwards.
What I want to say is that different file versions (as
discussed by you) involve different debian package
(version) dependencies already.
So why not drop the ".../hooks/program version" idea for
the sake of package interdependency, solely?
When packages register with doc-base through 'install-docs
-i ...', they do so one by one. Given that's correct, how
would doc-base be able to notify dhelp about _several_ new
docs (through 'program install') at a time? (The 'file
seperator' thing again.) Is there something like a
commit phase for 'install -i' so that all actions can be
fulfilled at once?
Please tell me if I'm complicating things :) and your
opinions.
Buy!
--
Daniel
mailto:daniel.nouri@con-fuse.org
______________________________________________________________________________
Wenn POP fur Sie mehr als nur Musik ist. Senden Sie Ihre SMS direkt aus
Outlook oder Netscape! http://freemail.web.de/features/?mc=021177
Reply to: