From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EnwX1-0007LH-GZ for garchives@archives.gentoo.org; Sun, 18 Dec 2005 11:16:47 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBIBG5Ac026652; Sun, 18 Dec 2005 11:16:05 GMT Received: from mail.genone.homeip.net (dslb-082-083-053-076.pools.arcor-ip.net [82.83.53.76]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBIBEFUi004185 for ; Sun, 18 Dec 2005 11:14:15 GMT Received: by mail.genone.homeip.net (Postfix, from userid 460) id C740C281F3; Sun, 18 Dec 2005 12:15:29 +0100 (CET) Received: from [192.168.0.2] (unknown [192.168.0.2]) by mail.genone.homeip.net (Postfix) with ESMTP id 7C69A281F1 for ; Sun, 18 Dec 2005 12:15:29 +0100 (CET) Message-ID: <43A53768.6070106@gentoo.org> Date: Sun, 18 Dec 2005 12:18:16 +0200 From: Marius Mauch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] glep 42 (news) round six References: <20051218041545.3d4c50d5@snowdrop.home> <20051218055047.GJ22142@nightcrawler.e-centre.net> <20051218062355.41fb99a0@snowdrop.home> <20051218072732.GK22142@nightcrawler.e-centre.net> In-Reply-To: <20051218072732.GK22142@nightcrawler.e-centre.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4-gr0-genone_0.7 (2005-06-05) on lyta.genone.homeip.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=7.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-gr0-genone_0.7 X-Archives-Salt: b5f44fea-d05f-4ca5-8472-c88a7d5056d3 X-Archives-Hash: ef4fa0486b6af53c1f5fcaeb2ee8efeb 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 >>| 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 -- gentoo-dev@gentoo.org mailing list