On Mon, Jan 14, 2008 at 08:11:08PM -0800, Daniel Burrows <[EMAIL PROTECTED]> was heard to say: > On Mon, Jan 14, 2008 at 06:16:58PM +0200, Eddy Petrișor <[EMAIL PROTECTED]> > was heard to say: > > On 14/01/2008, Daniel Burrows <[EMAIL PROTECTED]> wrote: > > To me (as a user) is really clear what should happen for the issue you > > raised: > > > > I simply don't care that there is another component behind aptitude > > that provides it with more info. As long as I don't see that component > > as a different application, which I don't in debtags' case, apt-get > > update/aptitude upadate should automatically pull in a debtags update. > > How does aptitude provide progress indication for a debtags download? > > What if something goes wrong (e.g., network error)? How does it get > indicated? On my computer, when I take the network interface down > "debtags update" exits successfully with no output. > > Does debtags ever write to standard error? (presumably it does, so > I'll have to write code to catch standard error so it doesn't scribble > on the screen) Does it have a standardized output protocol that I could > parse to extract messages or does it write plain text?
OK, I've looked a bit more at this. In the default configuration, it's perfectly fine to run "debtags update"; this just scavenges information from the apt cache and builds the debtags cache from it. Unfortunately, that's not the case when debtags is given a network source. In fact, enabling the example source (on "iterating.org") causes debtags, or rather wget invoked by debtags, to spew a bunch of information directly to the terminal. If the connection times out, as is happening right now, wget will retry twenty times (according to its manpage) before giving up. 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? 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? Daniel
