| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
|
| 5 |
R Hill wrote: |
| 6 |
> Craig Lawson wrote: |
| 7 |
> |
| 8 |
>> Comments? |
| 9 |
> |
| 10 |
> |
| 11 |
> This subject has also been brought up on the forum[1] very recently. |
| 12 |
> There have been some interesting ideas and alternatives posed that seem |
| 13 |
> workable. I was hoping some of the developers, if they have a moment, |
| 14 |
> could consider and critique these suggestions so we can come up with a |
| 15 |
> final solution that works for everybody. |
| 16 |
> |
| 17 |
> --de. |
| 18 |
> |
| 19 |
> |
| 20 |
> [1] http://forums.gentoo.org/viewtopic-t-360192.html |
| 21 |
> |
| 22 |
|
| 23 |
A small discussion was had on #gentoo-portage about issues relating to |
| 24 |
this. I had issues with the com_err upgrade slaughtering sshd and |
| 25 |
denying remote logon; although I got the e-mail from my script telling |
| 26 |
me what to do to upgrade cleanly I could not log in remotely to do it |
| 27 |
causing a short trek across campus to sit at the console and perform the |
| 28 |
fix. |
| 29 |
|
| 30 |
So, in at least this case ( and many others ) an upgrade path is |
| 31 |
provided. They know there is breakage, and they usually provide some |
| 32 |
knowledge of how to fix it. Thus the content we are looking for exists, |
| 33 |
but often times is missed or ends up getting to us at the wrong time ( |
| 34 |
after the fact, instead of prior ). |
| 35 |
|
| 36 |
In order to receive this helpful data we basically need 4 or 5 things. |
| 37 |
|
| 38 |
RESTRICT="Warning" |
| 39 |
pkg_warn() |
| 40 |
Features="Warning" |
| 41 |
PORTAGE_WARNLEVEL={0-5} ( in make.conf ) |
| 42 |
EBUILD_WARNLEVEL={1-5} ( in the ebuild ) |
| 43 |
patches to portage |
| 44 |
Developer awareness and use ( QA++ ). |
| 45 |
|
| 46 |
1. If RESTRICT="Warning" is set, and EBUILD_WARNLEVEL is less than or |
| 47 |
equal to PORTAGE_WARNLEVEL then pkg_warn() is called, otherwise it is |
| 48 |
skipped. |
| 49 |
2. If Features="Warning" is set, pkg_warn() will die pending some |
| 50 |
action ( to be determined, offhand I'd say put pkg_warn() after |
| 51 |
src_unpack() and have "emerge --warning-disable CPV" touch |
| 52 |
$WORKDIR/.warning ) If $WORKDIR/.warning exists then continue the build |
| 53 |
and assume that the admin has read the content of pkg_warn(). |
| 54 |
|
| 55 |
If you do not care about breakage, you can set PORTAGE_WARNLEVEL=0 which |
| 56 |
means that EBUILD_WARNLEVEL will always greater than PORTAGE_WARNLEVEL |
| 57 |
and pkg_warn() will never get called. |
| 58 |
|
| 59 |
If you care about extreme breakage only, you can set PORTAGE_WARNLEVEL=1 |
| 60 |
and only system critical breakage will be reported and halted. |
| 61 |
As PORTAGE_WARNLEVEL increases less critical breakage will be reported |
| 62 |
and halted by pkg_warn(). |
| 63 |
|
| 64 |
Why the suggestion is so complex: |
| 65 |
|
| 66 |
Aim high, and whittle away crap that people don't like ;) I originally |
| 67 |
planned on not having warnlevels, but figured developers would use the |
| 68 |
RESTRICT and pkg_warn() to warn about silly things and everyone's emerge |
| 69 |
globs would halt every 3 seconds with a WARNING error. Thus the crazy |
| 70 |
guy that actually cares when xmms breaks ( think the module split-off ) |
| 71 |
can have his WARNING and halted emerge while those of us who only care |
| 72 |
when critical packages have upgrade issues can set PORTAGE_WARNLEVEL to |
| 73 |
1 and just get the big ones. |
| 74 |
|
| 75 |
Needs: |
| 76 |
|
| 77 |
The suggestion could definately benefit from per-package FEATURES ( |
| 78 |
already in bugzilla ) so I can create a whitelist of things to halt on |
| 79 |
upgrade problems ( think base-system ) and I can then ignore everything |
| 80 |
else, even if it's WARNLEVEL is less or equal to the config |
| 81 |
specification ( remember pkg_warn() only halts with FEATURES="Warning"). |
| 82 |
|
| 83 |
Suggestions, critiques, laughing at over-engineering welcome ;) |
| 84 |
|
| 85 |
- -Ajec |
| 86 |
-----BEGIN PGP SIGNATURE----- |
| 87 |
Version: GnuPG v1.4.1 (GNU/Linux) |
| 88 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 89 |
|
| 90 |
iQIVAwUBQuHW5WzglR5RwbyYAQJxVQ//czHIcTkeLySoijE7TdQObdD11Cms9G5N |
| 91 |
hhP83qgU8kq7XIGmh33l+W4IT5Viq0lfnRYtMtFSGuMyVrPJDONOKK6WMg3412xd |
| 92 |
6Bc2DBdBeJoX2OTrlMTMpFSwSp4qXOz+yFk/rpy7A+wId1uWQjDAC1HUtht6ydmZ |
| 93 |
+4q/FBeuDiAOPadCybAZcRuUinV+QbqwaizrAYNPPEuUyeGxnmpfkt3DH/tcZboC |
| 94 |
eACSpB0srH+SwOlfw+52L91R7UIimn0wj9CQ+2qN7iv97/FNcyn7A+n4kXifikUn |
| 95 |
MdfaKJxjgLCftqTlWr6TWTqxDpt7MRi8n5gGIUgG0SUfmk9J/KOerD+TusruQ41c |
| 96 |
41kb4+C/q3Zn7DRreTeh7NgX1yOXqb5OAOFGjjfr1ROdWuqmbtNgA4hNXtsDyTG6 |
| 97 |
uoDkzmbUesLZ1eDW0aJNb6FJRHx3JdiayzOQ1siKus4uWmQVfZuirtjdkwajVkwV |
| 98 |
K2QvHlPZ82VKo0zd6u1sXZa4rUUJHRU8DhnHv5p9qAcwC0h63pgFaNcuZ/h+I2jX |
| 99 |
vu7/IozmAMQAcl2YTtfZTCOFEOGDr/aErco9+c1E7pG5BRIvljXhrPYuvaovykzS |
| 100 |
r42YzZ5YlUep1aKQwEthCYlnx7T8IyKywwtLYouC95BCXIYFt5mMgjELlWnp/uY4 |
| 101 |
hI5pTlHrRw0= |
| 102 |
=1s8S |
| 103 |
-----END PGP SIGNATURE----- |
| 104 |
-- |
| 105 |
gentoo-portage-dev@g.o mailing list |
Archives