Brian Harring wrote:
On Sun, Dec 18, 2005 at 06:23:55AM +0000, Ciaran McCreesh wrote:
On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]>
| You haven't stated how the 'package manager' will trigger the user's
| reader of choice for these targets. Should also extend this to allow
| a way to disable any news notices, lest someone's cronjob get hung
| displaying news (feature or not, it's needed).
The same way the package manager handles updating config files: it
won't. It'll just tell the user that some news items need reading.
And you'll personally handle all of the bug spam from feature requests
that --ask trigger $news_reader?
It's a logical extension, thus people will ask for it.
I don't think so.
How many people have asked for etc-update integration?
| implementation issue; you need locking on this. If portage has to
| farm out to the users reader of choice, then it needs to lock the
| file to keep readers/writers from screwing with each other.
We do? Marius told me it wasn't worth it.
I disagree. It's mainly contingent upon $news_reader being spawned
via --ask, although it *also* matters heavily if the user is flipping
through their news while a sync in the background is running- if the
utility updates on the way out, unless their is some advisorial
locking involved, you've just lost all of the new synced unread news.
To quote myself:
"Granted race conditions might be an issue (where the solution
complicates tools), but that's so minor I wouldn't really care about
it."
That I wouldn't care about it isn't a general recommendation to ignore
the issue. Yes, for a perfect solution it is required, but do we aim for
a perfect solution?
| > News items can be removed (by removing the news file from the main
| > tree) when they are no longer relevant, if they are made obsolete
| > by a future news item or after a long period of time. This is the
| > same as the method used for ``updates`` entries.
|
| implementation issue; updating unread/skip crap so it doesn't bloat
| is required, but time frame also matters (crap sync resulting in news
| getting removed, yet it still being valid, just missing from the
| local tree).
Hrm. We can't take the same approach here as we do with expiring
updates entries?
We expire updates? If so, someone might want to look at the updates
from 3 years back...
Yeah, mainly me dropping old files sometimes (happened two times so far
IIRC), so not a general policy documented anywhere (just doing it when I
get annoyed by portage re-applying ancient entries).
Another new issue nobody has mentioned yet:
The GLEP doesn't say anything about file permissions/ownership as in who
will/should be able to a) read news and b) modify the news-* files.
Without thinking too much about it I'd say a) users in portage group and
b) root.
Marius
--
[email protected] mailing list
