Daniel Nouri <[EMAIL PROTECTED]> 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...<[EMAIL PROTECTED]>.......<URL:http://www.onshored.com/>
