On Sun, 2005-11-13 at 01:05 +0900, Jason Stubbs wrote: > > It is my opinion that the news reading application need not be > > integrated into portage. As far as I have understood it, the only real > > thing that anyone has required portage itself to do is to > > *automatically* spit out "You have $n unread news messages. Please use > > $bleh to read them" at certain times (after sync, after --pretend, > > before/after a merge). I don't see this as being something very > > complex. I would assume that some extra code would need to be written > > into the sync code somewhere to sort the messages. > > This, I get. What I'm wondering about is the `emerge --news` that is referred > to every so often.
emerge --news is just what people have been calling the news reader. As far as I can see, unless you *want* portage to handle the news reading, it should *not* have a --news option. > To be honest, this is the part that I don't like the most. Integrating code > into portage to copy files here and there based on some predefined rules and > news readers reading and renaming files based on some predefined rules... > A filesystem based API just doesn't seem very robust to change. > > I'd prefer that either the post-sync handling code is not integrated into > portage and portage just triggers some external script - or - portage exposes > an API (via python and bash) for accessing and updating news items. I'd > prefer the latter but I get the impression that most prefer the former. I believe that we have been under the impression that you guys preferred to keep this out of portage as much as possible. I think an API built into portage *would* be the best method for this. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
