Re: [gentoo-dev] Re: Deleting old news items
On Sat, Jan 6, 2018 at 1:05 PM, Ulrich Mueller wrote: > Filtering in eselect news would be problematic: Obtaining the list > of items with "eselect news list" and e.g. reading them with "eselect > news read" are issued as separate commands, which requires that the > list of valid items does not change. However, time-based filtering > could cause a race condition, like an item expiring between execution > of the two commands. Would it be possible to make the expiration times use not the wall clock time, but the timestamp of the repository if one is available? That would not only be more predictable (can expire on repository manipulations only), but also better suited for updating severely outdated systems. You can advance the repository state by 1 year and read the news items as they were at that time, not half of them expired and hidden. Denis Lisov.
Re: [gentoo-dev] Re: Deleting old news items
On 01/06/2018 11:11 PM, Anders Thomson wrote: > Thanks. Which of the requirements requires transport to be in a > particular manner? I see implications on pm, but nothing on > transport. tl;dr; the PM knows which packages are installed on the specific system, a specific feed does not (although that doesn't exclude the possibility of getting feed of all messages, which is already part of git repository) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deleting old news items
On January 6, 2018 9:30:51 PM GMT+01:00, Alec Warner wrote: >On Sat, Jan 6, 2018 at 2:51 PM, Anders Thomson > >wrote: > >> >> >> As a non-dev... >> > >> >In fact, it is the PM that would do the filtering, before filling >the >> >list of unread news items in... >> >> How come news' transport is tied to the pm / package tree at all? It >would >> seem more natural to fetch news using e.g. rss and have a reader >(which i >> can configure) sort out what to fetch/display when. > > >https://www.gentoo.org/glep/glep-0042.html#requirements details the >whys. > Thanks. Which of the requirements requires transport to be in a particular manner? I see implications on pm, but nothing on transport. A -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Re: Deleting old news items
On Sat, Jan 6, 2018 at 2:51 PM, Anders Thomson wrote: > > > As a non-dev... > > > >In fact, it is the PM that would do the filtering, before filling the > >list of unread news items in... > > How come news' transport is tied to the pm / package tree at all? It would > seem more natural to fetch news using e.g. rss and have a reader (which i > can configure) sort out what to fetch/display when. https://www.gentoo.org/glep/glep-0042.html#requirements details the whys. -A > > Anders > >
Re: [gentoo-dev] Re: Deleting old news items
As a non-dev... > >In fact, it is the PM that would do the filtering, before filling the >list of unread news items in... How come news' transport is tied to the pm / package tree at all? It would seem more natural to fetch news using e.g. rss and have a reader (which i can configure) sort out what to fetch/display when. Anders
Re: [gentoo-dev] Re: Deleting old news items
On Sat, Jan 6, 2018 at 11:25 AM, Ciaran McCreesh < ciaran.mccre...@googlemail.com> wrote: > On Sat, 6 Jan 2018 08:18:19 -0500 > kuzetsa wrote: > > On 01/06/2018 05:05 AM, Ulrich Mueller wrote: > > >> On Sat, 6 Jan 2018, Duncan wrote: > > >> $ equery b news.eselect > > >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) > > >> So in that case it's not the PM, but eselect. > > > In fact, it is the PM that would do the filtering, before filling > > > the list of unread news items > > > in /var/lib/gentoo/news/news-gentoo.read. > > > > > > Filtering in eselect news would be problematic: Obtaining the list > > > of items with "eselect news list" and e.g. reading them with > > > "eselect news read" are issued as separate commands, which requires > > > that the list of valid items does not change. However, time-based > > > filtering could cause a race condition, like an item expiring > > > between execution of the two commands. > > > > The race condition could be addressed by issuing a warning > > at or around the time when expirations occur (midnight), > > with or without detecting specific expirations which may > > have occurred: > > How accurate is "around"? Obviously we'd need to introduce a user > configuration option so different users could set appropriate values > for their needs. > > Seriously though, all this complexity is just highlighting that dates > are a really bad way of deciding when a news item should expire, and > that if we need anything, it's more Display-If conditions. > > I rescind my patches; I'm fairly sure portage is broken and I don't really relish fixing it; I've already spent more than 2 hours working on this and this isn't worth spending more time on anyway. -A > -- > Ciaran McCreesh > >
Re: [gentoo-dev] Re: Deleting old news items
On Sat, 6 Jan 2018 08:18:19 -0500 kuzetsa wrote: > On 01/06/2018 05:05 AM, Ulrich Mueller wrote: > >> On Sat, 6 Jan 2018, Duncan wrote: > >> $ equery b news.eselect > >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) > >> So in that case it's not the PM, but eselect. > > In fact, it is the PM that would do the filtering, before filling > > the list of unread news items > > in /var/lib/gentoo/news/news-gentoo.read. > > > > Filtering in eselect news would be problematic: Obtaining the list > > of items with "eselect news list" and e.g. reading them with > > "eselect news read" are issued as separate commands, which requires > > that the list of valid items does not change. However, time-based > > filtering could cause a race condition, like an item expiring > > between execution of the two commands. > > The race condition could be addressed by issuing a warning > at or around the time when expirations occur (midnight), > with or without detecting specific expirations which may > have occurred: How accurate is "around"? Obviously we'd need to introduce a user configuration option so different users could set appropriate values for their needs. Seriously though, all this complexity is just highlighting that dates are a really bad way of deciding when a news item should expire, and that if we need anything, it's more Display-If conditions. -- Ciaran McCreesh
Re: [gentoo-dev] Re: Deleting old news items
On 01/06/2018 05:05 AM, Ulrich Mueller wrote: >> On Sat, 6 Jan 2018, Duncan wrote: >> $ equery b news.eselect >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) >> So in that case it's not the PM, but eselect. > In fact, it is the PM that would do the filtering, before filling the > list of unread news items in /var/lib/gentoo/news/news-gentoo.read. > > Filtering in eselect news would be problematic: Obtaining the list > of items with "eselect news list" and e.g. reading them with "eselect > news read" are issued as separate commands, which requires that the > list of valid items does not change. However, time-based filtering > could cause a race condition, like an item expiring between execution > of the two commands. > > Ulrich The race condition could be addressed by issuing a warning at or around the time when expirations occur (midnight), with or without detecting specific expirations which may have occurred: WARNING: [n] is about to / has expired, and the list order is about to / has just changed (as appropriate for list and read respectively) Otherwise just warn when the commands run near midnight. signature.asc Description: OpenPGP digital signature
