Re: future of dhelp
Daniel Nouri <daniel.nouri@con-fuse.org> writes:
> 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?
See, this won't work. Suppose I have doc-base version 0.9.0 which is
first cut with the hooks. So the dhelp that provides the hook depends
on doc-base >= 0.9.0. So far so good.
But suddenly, there's doc-base 0.10.0 which adds optional
internationalized doc-registration fields. Ok, suppose your script
can handle/ignore fields it doesn't understand. But suddenly its
choking because we're shooting it UTF8 source.
I could deal with this by having doc-base conflict with the current
dhelp which doesn't handle UTF8 docreg files -- but I don't know that
the next one will support it. And moreover, suddenly dhelp
registration is utterly broken. *Unless* I'm able to provide data in
a backward-compatable way until dhelp hooks are updated.
You see why having versioning built in has benefits, despite a littel
complexity.
> When packages register with doc-base through 'install-docs
> -i ...', they do so one by one.
No, one of the changes will be a simple top-level looping so it can do
many at once.
--
...Adam Di Carlo...<adam@onshored.com>.......<URL:http://www.onshored.com/>
Reply to: