At 22:47 Uhr +0000 13.01.2003, Finlay Dobbie wrote:
It might be good to discuss changes like this *before* applying them, not afterwards...I just checked in a patch to Fink CVS which reworks the package indexing code.
BTW, making indention changes and a real change at the same time (as in postinstall.pl) is something one should avoid, as it makes it virtually impossible to determine which changes were actually made, at least when one only eyeballs the commit mails (maybe I can make a cvs diff -w or something, gotta try it).
Previously, if we detected the db was out-of-date, we ignored the current one and rebuilt it from scratch. Now I made it so that if it detects a modified or new package, it injects the description for just the files that are modified.Mostly the problem you mentioned yourself, i.e. old packages are never removed. The first problem caused by this is that the index would never shrink, only grow. Next, it means that if for some reasons we have to revoke a package from CVS, it is not sufficient anymore to just remove it from CVS again - we also need to get people to issue a "fink reindex". That's the main reason I didn't do it that way.
However, there is no reliable way of pruning old package info. So, if you remove a package's info file, but don't re-index, the old info is still in the database and available to Fink, and so on. Can anybody see any problem with this?
On the other hand is the speedup gained by this. But the problem of old packages sticking around was precisely the reason I did not choose to follow this course of action in the past.
There is a reliable way to prune old package information, namely if we would record for each PkgInfo from which file it came. Then if those files are missing, one can remove the PkgInfo from the hash. Of course one has to deal with the possibility of multiple files providing the same PkgVersion (e.g. the same package sitting in both stable and unstable). You can detect removed file by the fact that their parent dir has a changed modification time. Alas, doing that might not be faster, or even slower, and of course involves additional code.
Do you cover the fact that when fink (the package manager) is updated, a reindex *has* to be done (after the update)?
Lastly, something neither the current nor the old version did: when the user adds/removes trees from fink.conf, a reindex should be done.
Max
--
-----------------------------------------------
Max Horn
Software Developer
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
