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.43) id 1DwCge-0004bw-Kl for garchives@archives.gentoo.org; Sat, 23 Jul 2005 05:36:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6N5ZNFi010320; Sat, 23 Jul 2005 05:35:23 GMT Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j6N5XAQW010507; Sat, 23 Jul 2005 05:33:11 GMT Received: from [192.168.2.171] (207-72-142-241.dovers_res_net.spartan-net.net [207.72.142.241] (may be forged)) (authenticated bits=0) by egr.msu.edu (8.13.4/8.13.4) with ESMTP id j6N5XjEs009163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jul 2005 01:33:45 -0400 (EDT) Message-ID: <42E1D6E5.70305@egr.msu.edu> Date: Sat, 23 Jul 2005 01:34:29 -0400 From: Alec Warner User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050704) 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, gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Proposal: pre-emerge advisories References: <1121318643.3180.6.camel@localhost.localdomain> In-Reply-To: X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 815d6d2b-aaa2-4137-8349-cad5fe61971f X-Archives-Hash: 4862e6f20543956ffbdf946fe156e508 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 R Hill wrote: > Craig Lawson wrote: > >> Comments? > > > This subject has also been brought up on the forum[1] very recently. > There have been some interesting ideas and alternatives posed that seem > workable. I was hoping some of the developers, if they have a moment, > could consider and critique these suggestions so we can come up with a > final solution that works for everybody. > > --de. > > > [1] http://forums.gentoo.org/viewtopic-t-360192.html > A small discussion was had on #gentoo-portage about issues relating to this. I had issues with the com_err upgrade slaughtering sshd and denying remote logon; although I got the e-mail from my script telling me what to do to upgrade cleanly I could not log in remotely to do it causing a short trek across campus to sit at the console and perform the fix. So, in at least this case ( and many others ) an upgrade path is provided. They know there is breakage, and they usually provide some knowledge of how to fix it. Thus the content we are looking for exists, but often times is missed or ends up getting to us at the wrong time ( after the fact, instead of prior ). In order to receive this helpful data we basically need 4 or 5 things. RESTRICT="Warning" pkg_warn() Features="Warning" PORTAGE_WARNLEVEL={0-5} ( in make.conf ) EBUILD_WARNLEVEL={1-5} ( in the ebuild ) patches to portage Developer awareness and use ( QA++ ). 1. If RESTRICT="Warning" is set, and EBUILD_WARNLEVEL is less than or equal to PORTAGE_WARNLEVEL then pkg_warn() is called, otherwise it is skipped. 2. If Features="Warning" is set, pkg_warn() will die pending some action ( to be determined, offhand I'd say put pkg_warn() after src_unpack() and have "emerge --warning-disable CPV" touch $WORKDIR/.warning ) If $WORKDIR/.warning exists then continue the build and assume that the admin has read the content of pkg_warn(). If you do not care about breakage, you can set PORTAGE_WARNLEVEL=0 which means that EBUILD_WARNLEVEL will always greater than PORTAGE_WARNLEVEL and pkg_warn() will never get called. If you care about extreme breakage only, you can set PORTAGE_WARNLEVEL=1 and only system critical breakage will be reported and halted. As PORTAGE_WARNLEVEL increases less critical breakage will be reported and halted by pkg_warn(). Why the suggestion is so complex: Aim high, and whittle away crap that people don't like ;) I originally planned on not having warnlevels, but figured developers would use the RESTRICT and pkg_warn() to warn about silly things and everyone's emerge globs would halt every 3 seconds with a WARNING error. Thus the crazy guy that actually cares when xmms breaks ( think the module split-off ) can have his WARNING and halted emerge while those of us who only care when critical packages have upgrade issues can set PORTAGE_WARNLEVEL to 1 and just get the big ones. Needs: The suggestion could definately benefit from per-package FEATURES ( already in bugzilla ) so I can create a whitelist of things to halt on upgrade problems ( think base-system ) and I can then ignore everything else, even if it's WARNLEVEL is less or equal to the config specification ( remember pkg_warn() only halts with FEATURES="Warning"). Suggestions, critiques, laughing at over-engineering welcome ;) - -Ajec -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQuHW5WzglR5RwbyYAQJxVQ//czHIcTkeLySoijE7TdQObdD11Cms9G5N hhP83qgU8kq7XIGmh33l+W4IT5Viq0lfnRYtMtFSGuMyVrPJDONOKK6WMg3412xd 6Bc2DBdBeJoX2OTrlMTMpFSwSp4qXOz+yFk/rpy7A+wId1uWQjDAC1HUtht6ydmZ +4q/FBeuDiAOPadCybAZcRuUinV+QbqwaizrAYNPPEuUyeGxnmpfkt3DH/tcZboC eACSpB0srH+SwOlfw+52L91R7UIimn0wj9CQ+2qN7iv97/FNcyn7A+n4kXifikUn MdfaKJxjgLCftqTlWr6TWTqxDpt7MRi8n5gGIUgG0SUfmk9J/KOerD+TusruQ41c 41kb4+C/q3Zn7DRreTeh7NgX1yOXqb5OAOFGjjfr1ROdWuqmbtNgA4hNXtsDyTG6 uoDkzmbUesLZ1eDW0aJNb6FJRHx3JdiayzOQ1siKus4uWmQVfZuirtjdkwajVkwV K2QvHlPZ82VKo0zd6u1sXZa4rUUJHRU8DhnHv5p9qAcwC0h63pgFaNcuZ/h+I2jX vu7/IozmAMQAcl2YTtfZTCOFEOGDr/aErco9+c1E7pG5BRIvljXhrPYuvaovykzS r42YzZ5YlUep1aKQwEthCYlnx7T8IyKywwtLYouC95BCXIYFt5mMgjELlWnp/uY4 hI5pTlHrRw0= =1s8S -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list