On Tuesday, January 14, 2003, at 02:51 am, Max Horn wrote:
I just checked in a patch to Fink CVS which reworks the package
indexing code.
It might be good to discuss changes like this *before* applying them,
not afterwards...
We can always back out the changes if needs be, and I had discussed it
briefly on #fink. I was under the impression this was something that
had been thought about in the past, but not implemented through lack of
time.
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).
I detailed the change in the ChangeLog, and it was only minuscule
(issues a fink index at the end).
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.
Well, the index will shrink if it is remade, as it will be every time a
new version of the package manager is released. Probably not an optimal
solution, granted, but I mean, it's hardly a massive file anyway.
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.
I asked what the policy was on this, and IIRC it was that we bump the
revision number anyway, to make sure we get rid of it from everyone.
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.
As far as I was aware, this was a wanted feature, and the reason it was
not implemented was because I hadn't actually gotten around to looking
at it when I implemented the cache anyway. Since I just recently found
a pocket of free time, I thought I should probably implement it.
Evidently I was wrong.
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.
I'd need to think about how to deal with dummy packages in this
situation.
Do you cover the fact that when fink (the package manager) is updated,
a reindex *has* to be done (after the update)?
Yes, that's what the change in the postinstall change was for.
Lastly, something neither the current nor the old version did: when
the user adds/removes trees from fink.conf, a reindex should be done.
Uhm, the code always used to check the modified date of fink.conf.
I'm going to go and back out my changes since everybody is up in arms.
-- Finlay
-------------------------------------------------------
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
