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

Reply via email to