-----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-portage-dev@gentoo.org mailing list

Reply via email to