On Sat, Jan 19, 2008 at 07:36:29AM -0800, Daniel Burrows wrote: I finally manage to contribute to this thread, of which I care a lot.
> So, I suppose I could get into the business of trying to parse the > output of "wget" ... but that seems fundamentally dicey to me. On the > other hand, I see a "--local" option to "debtags update" that will > suppress network updates. So does another option called "--reindex". > The manpage doesn't make the distinction clear, but I guess that --local > will scan the apt cache and extract tag information, whereas --reindex > just rebuilds the debtags index? During a normal debtags update, debtags tries to acquire new versions of every tag source, then caches them in /var/lib/debtags. It the runs through the cached versions, merging them into the final debtags database[1], which also gets indexed[2]. With --local, it goes through the same process but avoids acquiring new versions of those tag sources that require the network; it will however use old cached versions of them when creating the merged debtags database. Therefore, --local is the thing you would want to call from aptitude, as it's supposed to be quick, trouble-free and work without network. Indeed there's a documentation problem with --reindex, I myself had to go and look at the sources to see what it does. What is does is just to skip the "fetch new versions" phase altogether and only reuse the data from the cache: this skips, for example, reextracting tags from the Packages file. I'm not sure why it would make sense to use it instead of --local, and I'm now wondering if it's a relic from the past, when any slight change in the apt index would invalidate the debtags index. By the way, now the apt index can freely be updated without invalidating the debtags index; just, you may miss the tags of those packages that jave just been added to the apt index. [1] /var/lib/debtags/package-tags and /var/lib/debtags/vocabulary [2] /var/lib/debtags/*.idx > So, to summarize: it appears that "/usr/bin/debtags --local > /dev/null > 2>&1" > will update the debtags cache so it reflects the current state of the apt > database, it should be run after updating the apt lists, and people who > have enabled a network source for debtags are responsible for updating > that source themselves from time to time until debtags gets an apt > method and/or pkgAcquire::Item subclass. Does that seem reasonable? Yes, it's reasonable. Also, debtags ships with a cron job that runs a full debtags update once a day, and this will take care of updating those remote sources. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
