Le 10 avr. 2006 à 19:27, David R. Morrison a écrit :
Dear Fink developers,
For some time now, 'fink validate' has attempted to enforce a
(poorly-documented) policy about scrollkeeper files: if a
scrollkeeper file is present, then the package should depend on
scrollkeeper and scrollkeeper-update should be called in
postinstall and postremove scripts.
There has been an objection to this from a fink developer who quite
reasonably points out that his package has documentation of all
sorts, including scrollkeeper files, but that one should not be
forced to install scrollkeeper to install his package. He found an
alternate solution for his scripts: if scrollkeeper-update is
present, then it is run.
Note that this solves the problem quite nicely, since scrollkeeper
itself runs scrollkeeper-update upon installation.
Do people agree that this is OK? We could even go further, and add
a fink declaration "UpdateScrollkeeper: true" analogous to
"UpdatePOD: true" which would let us put the requiste lines into
the scripts automatically. Good idea or not?
In an ideal world, this would be perfect. Alas, we're not in such a
world.
From what I've seen so far:
1 - Some packages need to run scrollkeeper-update -q in
PostInstScript and PostRmScript, even if they don't install any omf
files, because they need to construct an index file of all doc
installed as init file. This is the case for example for yelp (i.e.
yelp-viewer in fink)
2 - Some packages have a preinstall script for omf files, which is
correct from the Fink's point of view, i.e. they install the files in
the build root directory.
3. Some others don't install anything related to omf files, if the --
disable-scrollkeeper-update is given as configure option, or if
scrollkeeper is not found.
4. Some others install directIy into %p, some other in build root and
update also in build root.
5. Not using scrollkeeper-update can lead to missing features at run
time, i.e. abitlity to view the doc from inside the application for
example.
Normally, each time you install or remove an omf file or change the
location of an omf file, scrollkeeper-update should be run. Otherwise
it don't know anything about the location of the file, hence the
installation of the doc files are useless in that case, since they
cannot be accessed.
So that the solution to say, let people install scrollkeeper if they
want, does not seem to me a good solution. Because, then, they have
to run scrollkeeper-update each time an omf file is installed or
changed or removed, and I don't see how they can know that, since the
installation is quiet anyway.
Another thought (I cannot remember if it verifies though): what
happens if an omf file is installed without running scrollkeeper-
update and then we use purge all (or fink cleanup or analog remove
all script). Will the scrollkeeper directories be emptied? Just a
parallel to gconf, where not running systematically the script leads
to a gconf directory never emptied.
Please, don't take that as negative. It's just that things are not
perfect.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel