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 1MywXT-0001FK-8e for garchives@archives.gentoo.org; Fri, 16 Oct 2009 23:48:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C864E06FA; Fri, 16 Oct 2009 23:48:50 +0000 (UTC) Received: from jolexa.net (jolexa.net [69.164.197.24]) by pigeon.gentoo.org (Postfix) with ESMTP id 1EA4AE06FA for ; Fri, 16 Oct 2009 23:48:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by jolexa.net (Postfix) with ESMTP id D7A505B7A4 for ; Fri, 16 Oct 2009 23:48:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at jolexa.net Received: from jolexa.net ([127.0.0.1]) by localhost (jolexa.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+eMF2SYCUKW for ; Fri, 16 Oct 2009 23:48:49 +0000 (UTC) Received: from [192.168.1.110] (c-24-245-20-2.hsd1.mn.comcast.net [24.245.20.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jolexa.net (Postfix) with ESMTPSA id 71B1D5B781 for ; Fri, 16 Oct 2009 23:48:49 +0000 (UTC) Message-ID: <4AD90660.5040903@gentoo.org> Date: Fri, 16 Oct 2009 18:48:48 -0500 From: Jeremy Olexa User-Agent: Thunderbird 2.0.0.23 (X11/20090920) 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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 77661742-e63d-46be-b25b-0daa9aed68c0 X-Archives-Hash: 21b89aab2324a944d479b9dec37c4df5 Daniel Bradshaw wrote: > 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 on > with working. > Other packages, like apache and ssh, need are more fragile and need plenty > 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 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 explicitly. > > `emerge -vaut @safe` would be kinda useful. > > Just a thought. > > Regards, > Daniel > I am seeing a trend here because this email aligns with the thoughts on the openrc email thread a few days ago. That being said, no clue how to implement it. Actually I think that marking a package as "demanding" would be the more useful than "safe" because probably 95+% of packages are "safe" But, as with a request for an indicator for compile times[1], I think this proposal would be a failure in general because of subjective opinions between people. I would consider apache/lighttpd as being "safe" after initial configuration as long as you don't automatically etc-update. But you or someone else would not think it was safe. Therefore, nice in theory but probably wouldn't work in practice. Nice idea, keep them rolling and I'm not trying to kill the thread. :) -Jeremy [1]: http://bugs.gentoo.org/288193