GLEP 42 says about "News Item Removal": "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." However, removal of the file from metadata/news/ is not sufficient. The news-${repoid}.{unread,read,skip} files must also be updated. Unfortunately the GLEP doesn't say if this is the duty of the package manager or the newsreading client.
How does it hurt if old news items are left in read or skip?
(In reply to comment #1) > How does it hurt if old news items are left in read or skip? skip doesn't hurt, but if there's a non-existing item in read (or unread), the following happens: With eselect-1.1.3 and eselect-news-20080320: $ eselect news read all 2009-10-06-test-removed /usr/share/eselect/modules/news.eselect: line 92: /usr/portage/metadata/news/2009-10-06-test-removed/2009-10-06-test-removed.en.txt: No such file or directory /usr/share/eselect/modules/news.eselect: line 99: /usr/portage/metadata/news/2009-10-06-test-removed/2009-10-06-test-removed.en.txt: No such file or directory With eselect-1.2.3: $ eselect news read all 2009-10-06-test-removed !!! Error: Error reading item "2009-10-06-test-removed" I think that we shouldn't throw such error messages at users, but I also don't see what could be done about it in the eselect module. There's no good way to distinguish between a removed item and a real error condition.
What happens if an overlay supplies news items, and the user then removes that overlay?
So what do you suggest? Silently ignore items that are in {read,unread} but have no corresponding file in metadata/news/?
I don't think the overlay case leaves us with a reasonable alternative.
(In reply to comment #2) > With eselect-1.2.3: > $ eselect news read all > 2009-10-06-test-removed > !!! Error: Error reading item "2009-10-06-test-removed" Maybe if we just change this to say "this item no longer exists" instead of screaming "!!! Error", so it won't scare the user so much.
(In reply to comment #6) > Maybe if we just change this to say "this item no longer exists" instead of > screaming "!!! Error", so it won't scare the user so much. Yeah, that'd probably work. Would need to give the user a way to purge such items too.
(In reply to comment #7) > (In reply to comment #6) > > Maybe if we just change this to say "this item no longer exists" instead of > > screaming "!!! Error", so it won't scare the user so much. Right, I'll downgrade the error to a warning then: write_warning_msg "News item \"${item}\" no longer exists" > Yeah, that'd probably work. Would need to give the user a way to purge such > items too. It's moved from "unread" to "read" when it's encountered, and "purge" works the normal way. I don't think that we need anything more complicated here.
Considering this as fixed, as the news module of eselect-1.2.4 (released today) displays a warning only. Reopen (and attach a patch ;-) if you think that this is still unsatisfactory.
