Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Tuesday 26 July 2005 00:27, Georgi Georgiev wrote: One more thing. has_version would not necessarily detect the version we are upgrading from (i.e., the version that will be removed after installation) if there is a slotted package. Could that become a problem? The portage that this will be put into (if it is done) will support slot-based atoms. Brian has brought up some issues with it being done via an ebuild function, though. Not sure what they are as it's pretty much the same as it's pretty much the same as pkg_fetch(), but... Another alternative is to use metadata.xml for this stuff. That would have the advantage of being able to create a separate tool now without having to change any ebuild semantics. It also has the added bonus that information could be queried regardless as to what is installed. For example, (re-)accessing important udev upgrade notes after upgrading. -- Jason Stubbs pgpxPzX4DePQ2.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Sat, 2005-07-23 at 11:18 -0400, Greg KH wrote:
On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote:
Georgi Georgiev wrote:
Just to make sure I am not missing something.
Does this cover the
- If you are upgrading from a version of udev prior to 046 ...
- If you are upgrading from a version of udev prior to 050 ...
- If you are upgrading from a version of udev prior to 057 ...
- If you are upgrading from a version of udev prior to 059 ...
cases automatically? I.e. *not* showing irrelevant warnings on every
upgrade/rebuild.
The writer of pkg_warn() could do this, it's still in the ebuild and
could use the normal ebuild functions to determine what the user is
running ( has_version() and whatnot ) and then run a case statement on that.
Great, anyone care to send me a patch for the udev ebuild to do this so
not everyone sees this message? It will only get longer over time...
Something like this maybe? (Yes, I know using $T will be frowned upon,
but not much else you can do. Also, might use has_version(), but that
is more difficult to parse, and I figured you normally only want those
for system udev ...)
--
Martin Schlemmer
Index: udev-063.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/sys-fs/udev/udev-063.ebuild,v
retrieving revision 1.2
diff -u -r1.2 udev-063.ebuild
--- udev-063.ebuild 17 Jul 2005 06:10:06 - 1.2
+++ udev-063.ebuild 25 Jul 2005 07:46:59 -
@@ -135,6 +135,15 @@
}
pkg_preinst() {
+ local udev_version=$(udev -V 2/dev/null)
+
+ if [ -n ${udev_version} ]
+ then
+ # Strip leading '0'
+ udev_version=${udev_version##0}
+ echo ${udev_version} ${T}/udev_version
+ fi
+
if [ -f ${ROOT}/etc/udev/udev.config -a \
! -f ${ROOT}/etc/udev/udev.rules ]
then
@@ -155,6 +164,8 @@
}
pkg_postinst() {
+ local udev_version=0
+
if [ ${ROOT} = / -a -n `pidof udevd` ]
then
killall -15 udevd /dev/null
@@ -162,33 +173,48 @@
killall -9 udevd /dev/null
fi
+ [ -f ${T}/udev_version ] udev_version=$( ${T}/udev_version)
+
# people want reminders, I'll give them reminders. Odds are they will
# just ignore them anyway...
- ewarn Note: If you are upgrading from a version of udev prior to 046
- ewarn and you rely on the output of udevinfo for anything, please
- ewarn either run 'udevstart' now, or reboot, in order to get a
- ewarn up-to-date udev database.
- ewarn
- ewarn Note: If you are upgrading from a version of udev prior to 050
- ewarn and you had written some custom permissions rules, please
- ewarn realize that the permission rules are now part of the main
- ewarn udev rules files and are not stand-alone anymore. This means
- ewarn you need to rewrite them.
- ewarn
- ewarn Note: If you are upgrading from a version of udev prior to 057
- ewarn and you have written custom rules, and rely on the etc/dev.d/
- ewarn functionality, please read the RELEASE-NOTES file for details
- ewarn on what has changed with this feature, and how to change your
- ewarn rules to work properly.
- ewarn
- ewarn Note: If you are upgrading from a version of udev prior to 059
- ewarn and you have written custom rules, and rely on the etc/dev.d/
- ewarn functionality, or the etc/hotplug.d functionality, or just
- ewarn want to write some very cool and power udev rules, please
- ewarn read the RELEASE-NOTES file for details on what has changed
- ewarn with this feature, and how to change your rules to work properly.
+ if [ ${udev_version} -lt 46 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 046
+ ewarn and you rely on the output of udevinfo for anything, please
+ ewarn either run 'udevstart' now, or reboot, in order to get a
+ ewarn up-to-date udev database.
+ echo
+ fi
+ if [ ${udev_version} -lt 50 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 050
+ ewarn and you had written some custom permissions rules, please
+ ewarn realize that the permission rules are now part of the main
+ ewarn udev rules files and are not stand-alone anymore. This means
+ ewarn you need to rewrite them.
+ echo
+ fi
+ if [ ${udev_version} -lt 57 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 057
+ ewarn and you have written custom rules, and rely on the etc/dev.d/
+ ewarn functionality, please read the RELEASE-NOTES file for details
+ ewarn on what has changed with this feature, and how to change your
+ ewarn rules to work properly.
+ echo
+ fi
+ if [ ${udev_version} -lt 59 ]
+ then
+ ewarn Note: If you are upgrading from a version of udev prior to 059
+ ewarn and you have written custom rules, and rely on the etc/dev.d/
+ ewarn functionality, or the etc/hotplug.d functionality, or just
+ ewarn want to
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Monday 25 July 2005 16:51, Martin Schlemmer wrote: On Sat, 2005-07-23 at 11:18 -0400, Greg KH wrote: On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote: Georgi Georgiev wrote: Just to make sure I am not missing something. Does this cover the - If you are upgrading from a version of udev prior to 046 ... - If you are upgrading from a version of udev prior to 050 ... - If you are upgrading from a version of udev prior to 057 ... - If you are upgrading from a version of udev prior to 059 ... cases automatically? I.e. *not* showing irrelevant warnings on every upgrade/rebuild. The writer of pkg_warn() could do this, it's still in the ebuild and could use the normal ebuild functions to determine what the user is running ( has_version() and whatnot ) and then run a case statement on that. Great, anyone care to send me a patch for the udev ebuild to do this so not everyone sees this message? It will only get longer over time... Something like this maybe? (Yes, I know using $T will be frowned upon, but not much else you can do. Also, might use has_version(), but that is more difficult to parse, and I figured you normally only want those for system udev ...) Combining the pkg_preinst and pkg_postinst parts (and removing the usage of $T ;), that pretty much shows exactly what the proposed pkg_warn would look like. Only difference being that it would be executed before emerging starts. -- Jason Stubbs pgpu2fDVP6dN0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Mon, 2005-07-25 at 20:53 +0900, Jason Stubbs wrote: On Monday 25 July 2005 16:51, Martin Schlemmer wrote: On Sat, 2005-07-23 at 11:18 -0400, Greg KH wrote: On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote: Georgi Georgiev wrote: Just to make sure I am not missing something. Does this cover the - If you are upgrading from a version of udev prior to 046 ... - If you are upgrading from a version of udev prior to 050 ... - If you are upgrading from a version of udev prior to 057 ... - If you are upgrading from a version of udev prior to 059 ... cases automatically? I.e. *not* showing irrelevant warnings on every upgrade/rebuild. The writer of pkg_warn() could do this, it's still in the ebuild and could use the normal ebuild functions to determine what the user is running ( has_version() and whatnot ) and then run a case statement on that. Great, anyone care to send me a patch for the udev ebuild to do this so not everyone sees this message? It will only get longer over time... Something like this maybe? (Yes, I know using $T will be frowned upon, but not much else you can do. Also, might use has_version(), but that is more difficult to parse, and I figured you normally only want those for system udev ...) Combining the pkg_preinst and pkg_postinst parts (and removing the usage of $T ;), that pretty much shows exactly what the proposed pkg_warn would look like. Only difference being that it would be executed before emerging starts. Currently: - if everything is moved to pkg_preinst(), the message will not show at the end of the merge, so much higher chance of getting missed. - if everything is moved to pkg_postinst(), $udev_version will be the new version, and be of no use. - if you meant that this is for the pkg_warn() ... it still wont really help that much, as it will differ from before/after the update :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
On Sat, Jul 23, 2005 at 10:53:15AM -0400, Alec Warner wrote: Georgi Georgiev wrote: Just to make sure I am not missing something. Does this cover the - If you are upgrading from a version of udev prior to 046 ... - If you are upgrading from a version of udev prior to 050 ... - If you are upgrading from a version of udev prior to 057 ... - If you are upgrading from a version of udev prior to 059 ... cases automatically? I.e. *not* showing irrelevant warnings on every upgrade/rebuild. The writer of pkg_warn() could do this, it's still in the ebuild and could use the normal ebuild functions to determine what the user is running ( has_version() and whatnot ) and then run a case statement on that. Great, anyone care to send me a patch for the udev ebuild to do this so not everyone sees this message? It will only get longer over time... thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
maillog: 23/07/2005-15:04:06(+0900): Jason Stubbs types
On Saturday 23 July 2005 14:34, Alec Warner wrote:
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++ ).
Too complex. RESTRICT=warn + pkg_warn() is enough.
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().
Why make it so difficult? Why die at all? The point of having pkg_warn()
separate to pkg_setup() is so that dieing is not necessary and the
information can be given up front.
`emerge --warnings -uDvp world` could list the warnings after the upgrade
list for example. FEATURES=warnings can permanently enable --warnings
similar to FEATURES=buildpkg works.
Does this not cover all bases already?
Just to make sure I am not missing something.
Does this cover the
- If you are upgrading from a version of udev prior to 046 ...
- If you are upgrading from a version of udev prior to 050 ...
- If you are upgrading from a version of udev prior to 057 ...
- If you are upgrading from a version of udev prior to 059 ...
cases automatically? I.e. *not* showing irrelevant warnings on every
upgrade/rebuild.
--
\/ Georgi Georgiev \/ Are we THERE yet?\/
/\[EMAIL PROTECTED]/\ /\
\/ +81(90)2877-8845 \/ \/
pgpR9WKGX7agL.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
-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
[gentoo-portage-dev] Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
-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
[gentoo-dev] Re: Proposal: pre-emerge advisories
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 -- gentoo-dev@gentoo.org mailing list
