| 1 |
Marius Mauch wrote: [Fri Nov 11 2005, 11:40:53AM CST] |
| 2 |
> Things that I'd like to be changed/I'm not completely sure about: |
| 3 |
> - filtering of news items: |
| 4 |
> I've already asked a similar question in another mail (in other |
| 5 |
> context) without an answer, but how many news items do people believe |
| 6 |
> will exist at any given time? Depending on the actual implementation it |
| 7 |
> might be required to scan all existing news items which could take some |
| 8 |
> time if there is a large number of them (say, more than a few hundred) |
| 9 |
> It's clear that noone can present accurate numbers, just after some |
| 10 |
> rough estimates here. |
| 11 |
|
| 12 |
The GLEP sets the bar pretty high for what should be a significant news |
| 13 |
item, so my extremely rough guess is that 30/year would be on the quite |
| 14 |
high side. Ideally this system should extend, not supplant, the normal |
| 15 |
einfo/ewarn notices. (Um, what is the status of the einfo/ewarn message |
| 16 |
system that went into CVS. Any ETA on when it's going to be back-ported |
| 17 |
to current portage? I could see where there might be a tendency to |
| 18 |
abuse the news system if the messaging stuff is still unavailable.) |
| 19 |
|
| 20 |
> Also it might be useful for this filtering to be an external tool using |
| 21 |
> portage functions and called by portage (see also below). Although this |
| 22 |
> could be considered an implementation detail as it's mostly transparent |
| 23 |
> for ebuild devs/users. |
| 24 |
|
| 25 |
I'm not quite sure what you're saying here. |
| 26 |
|
| 27 |
> - local storage of news items / "read" attribute: |
| 28 |
> I don't really the like the copy-if-new feature and handling at the fs |
| 29 |
> level, I'd use a file that lists the ids of news items (potentially |
| 30 |
> with a timestamp and/or status field). I don't see any benefits of |
| 31 |
> having redundancy here, and accessing the news in $PORTDIR is simple |
| 32 |
> enough. Granted race conditions might be an issue (where the solution |
| 33 |
> complicates tools), but that's so minor I wouldn't really care about |
| 34 |
> it. |
| 35 |
|
| 36 |
My impression was that ciaranm was thinking of using something akin to a |
| 37 |
Maildir mailbox to hold and handle news items, because then one can |
| 38 |
leverage an insane amount of existing stuff. *Shrug* I also wouldn't |
| 39 |
object to a flat list of pointers to relevant files. |
| 40 |
|
| 41 |
> Another thing that's unclear: "Whenever relevant unread news items are |
| 42 |
> found, emerge will copy or symlink the news file into |
| 43 |
> /var/lib/gentoo/news/." |
| 44 |
> This "Whenever ... are found" is too vague, should this apply to emerge |
| 45 |
> --sync, any emerge operation, any "import portage" call or what? This |
| 46 |
> isn't just an implementation detail. |
| 47 |
|
| 48 |
I was going to say that the only way new news items could appear is |
| 49 |
during an emerge --sync, but of course that's not true for people who |
| 50 |
either add an overlay or use CVS. I'd be comfortable with making it run |
| 51 |
only at --sync time, or if it were triggered explicitly (--check-news, |
| 52 |
or some such). |
| 53 |
|
| 54 |
-g2boojum- |
| 55 |
-- |
| 56 |
Grant Goodyear |
| 57 |
Gentoo Developer |
| 58 |
g2boojum@g.o |
| 59 |
http://www.gentoo.org/~g2boojum |
| 60 |
GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 |
Archives