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