From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Mz1vT-00045o-Gx for garchives@archives.gentoo.org; Sat, 17 Oct 2009 05:33:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC9AEE07B5; Sat, 17 Oct 2009 05:33:57 +0000 (UTC) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by pigeon.gentoo.org (Postfix) with ESMTP id BA473E07B5 for ; Sat, 17 Oct 2009 05:33:56 +0000 (UTC) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id E12DA4B0091 for ; Sat, 17 Oct 2009 07:33:53 +0200 (CEST) Received: from [192.168.0.13] (bne75-10-88-178-16-229.fbx.proxad.net [88.178.16.229]) by smtp2-g21.free.fr (Postfix) with ESMTP id F23D44B0076 for ; Sat, 17 Oct 2009 07:33:50 +0200 (CEST) Message-ID: <4AD9571A.8010602@gentoo.org> Date: Sat, 17 Oct 2009 07:33:14 +0200 From: =?ISO-8859-1?Q?R=E9mi_Cardona?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New ebuild metadata to mark how robust the package is? References: <1255733421-30950-mlmmj-4f4db363@lists.gentoo.org> <7486f8688d881f8d4a987199cb9ec8ea.squirrel@core-mail.net> In-Reply-To: <7486f8688d881f8d4a987199cb9ec8ea.squirrel@core-mail.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2f250aae-69f8-4a4a-b8a8-705baab6a47e X-Archives-Hash: ad724911d5a8e5710b1ae9993f3195f9 Hi Daniel, Le 17/10/2009 01:29, Daniel Bradshaw a =E9crit : > So as I say, it occurs to me that most people probably follow some > variation of this selective upgrade method. > It might be handy to have some kind of metadata in the ebuilds that can= be > used to indicate a package that is "demanding". > Then that flag could be used to highlight the package on a dep tree, or > optionally to block the emerge unless the package is specified explicit= ly. IMHO, we already have the infrastructure for such info. We have elog and=20 news items. Now we (gentoo devs) are finally starting to add news items for bigger=20 updates (gnome, X, java, etc) and that's a good thing. But we definitely=20 cannot and should not use news items for minor upgrades. elog is much better suited for such upgrade notices. However, since elog was put in portage, ebuilds have been using=20 elog/ewarn/einfo _way_ too much. We're now at a point where the elog=20 output at the end of an emerge phase is just _useless_ because of all=20 the noise. And with your metadata proposal, I'm worried the same thing will happen.=20 Devs will enable the "troublesome" flag for a release, forget to remove=20 it for the next bump and a few months later, half the packages in=20 portage are labeled as such. I really don't want to sound like I want to kill your idea but I'm=20 somewhat doubtful it'll really work given our track record with other=20 such infrastructure. Cheers :) R=E9mi