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 1Myw9n-0002GX-K3 for garchives@archives.gentoo.org; Fri, 16 Oct 2009 23:24:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 919FCE0798; Fri, 16 Oct 2009 23:24:22 +0000 (UTC) Received: from mx.core-mail.net (unknown [89.238.157.246]) by pigeon.gentoo.org (Postfix) with ESMTP id 62D4AE0798 for ; Fri, 16 Oct 2009 23:24:22 +0000 (UTC) Received: by mx.core-mail.net (Postfix, from userid 81) id 2D8FD1526A8E; Fri, 16 Oct 2009 23:29:00 +0000 (UTC) Received: from 89.238.157.212 (SquirrelMail authenticated user daniel@core-mail.net) by core-mail.net with HTTP; Fri, 16 Oct 2009 23:29:00 -0000 (UTC) Message-ID: <7486f8688d881f8d4a987199cb9ec8ea.squirrel@core-mail.net> In-Reply-To: <1255733421-30950-mlmmj-4f4db363@lists.gentoo.org> References: <1255733421-30950-mlmmj-4f4db363@lists.gentoo.org> Date: Fri, 16 Oct 2009 23:29:00 -0000 (UTC) Subject: [gentoo-dev] New ebuild metadata to mark how robust the package is? From: "Daniel Bradshaw" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.4.17 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 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9f6017b4-0237-46ac-b316-a3b0c2a6e682 X-Archives-Hash: 6695b1a80e90ea589bb024cd623d5de5 Hi all, It occurs to me that my work flow when doing updates follows a fairly predictable (and probably common) pattern. The obvious next step is to wonder why no one though of automating it... When doing updates I tend to look through the package list and classify things based on how likely they are to break. Some packages, like findutils, are pretty robust and generally just get o= n with working. Other packages, like apache and ssh, need are more fragile and need plent= y of configuration. Packages from the second group want emerging on their own, or in small groups, the better to keep an eye out for notices about things that might break, to update configs, and to check that they're running happily. Once the update list is reduced to packages from the first group it's fairly safe to run emerge -u world and not worry about things exploding too badly. 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 b= e 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 explicitly= . `emerge -vaut @safe` would be kinda useful. Just a thought. Regards, Daniel