From: Alec Warner <warnera6@egr.msu.edu>
To: gentoo-dev@lists.gentoo.org, gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
Date: Sat, 23 Jul 2005 01:34:29 -0400 [thread overview]
Message-ID: <42E1D6E5.70305@egr.msu.edu> (raw)
In-Reply-To: <dbfbcv$bv7$1@sea.gmane.org>
-----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
next prev parent reply other threads:[~2005-07-23 5:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-14 5:24 [gentoo-dev] Proposal: pre-emerge advisories Craig Lawson
2005-07-14 7:17 ` Kevin F. Quinn
2005-07-14 7:36 ` Robin H. Johnson
2005-07-14 7:52 ` Georgi Georgiev
2005-07-14 14:22 ` Chris White
2005-07-18 4:32 ` [gentoo-dev] " R Hill
2005-07-23 5:34 ` Alec Warner [this message]
2005-07-23 6:04 ` Jason Stubbs
2005-07-23 13:32 ` Georgi Georgiev
2005-07-23 14:53 ` Alec Warner
2005-07-23 15:18 ` Greg KH
2005-07-25 7:51 ` Martin Schlemmer
2005-07-25 11:53 ` Jason Stubbs
2005-07-25 13:09 ` Martin Schlemmer
2005-07-25 13:33 ` Jason Stubbs
2005-07-25 15:26 ` Martin Schlemmer
2005-07-25 15:27 ` Georgi Georgiev
2005-07-26 10:31 ` Jason Stubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42E1D6E5.70305@egr.msu.edu \
--to=warnera6@egr.msu.edu \
--cc=gentoo-dev@lists.gentoo.org \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox