[gentoo-dev] Proposal: pre-emerge advisories
Craig Lawson
discovered that my CD-ROM drive went missing and my lovingly crafted
gnome menus were trashed by Gnome 2.10 and no longer editable. Oh joy,
another portage upgrade surprise. Some rummaging around in the Gentoo
forums sent me in the right direction and the CD-ROM was handily fixed.
But the menus were more complicated and I reverted Gnome.
Not the first time this has happened. Friends, I won't bore you with
tales of my past singeing, as I sense your hand itching towards your
Flame On! button. Instead, I have a proposal for discussion.
What I'd like to see *before* I upgrade is a list of advisories about
what trouble I'm in for. By the time most people upgrade a package,
someone's been there before and felt the pain. The answers, or at least
the warnings, are in the Forums. Yet searching the forums before
upgrading each package is not practical. Similarly, the build logs are
99% stuff I don't care to read and 1% that I really do. How to find it?
Better yet, I'd like to see it *before* I build.
Currently that stuff comes from each ebuild's post-install procedure,
however I don't think that's the best place for it: it's not easy to
change or amend (gotta be the package maintainer), it's risky to change
(too easy to introduce a syntax error), and it isn't specific to
individual situations.
To be more concrete, I'm thinking of something like a database with
three entries per record: current package+version, target package
+version, and some advisory text. For example, a few useful entries
would be:
current: any
target: =gnome-base/gnome-menus-2.10.0
advisory: Menu editing disabled until follow-up release.
Work-around is to install Python 4 + smeg. See
forum topic http://forums.gentoo.org/blah...
and:
current: <sys-fs/udev-60
target: >=sys-fs/udev-60
advisory: Rules file changed syntax. Preserve old rules file
and be prepared to rewrite.
and:
current: <kernel/vanilla-sources-2.6.11.11
target: =kernel/vanilla-sources-2.6.11.11
advisory: ide-cd no longer loaded by default. Add to
/etc/modules.autoload/kernel2.6
and when emerge figures out what it's going to build, the "--advise"
option (let's say) tells it to consult the database and issues a report.
Simple as that.
The database could be hosted on a Gentoo server, though it might be
better delivering it along with the "emerge sync" data and have the
build machine do all the work. Data could be stored in a single file, or
distributed throughout /usr/portage as ebuilds are.
Regardless of implementation, the main goals are:
1. Adding or modifying advisories is relatively easy. Doesn't require
programming skills.
2. Adding an advisory in no way risks an ebuild file. An ebuild is
executable code and no one has time to chase down syntax errors.
Advisories are separate.
3. You don't need to be the package maintainer to do it (though at this
point I'm not sure who would -- maybe a collaboration of forum
moderators and package maintainers?).
Comments?
Best Regards,
Craig.
--
gento...@gentoo.org mailing list
Chris White
> what trouble I'm in for. By the time most people upgrade a package,
> someone's been there before and felt the pain. The answers, or at least
> the warnings, are in the Forums. Yet searching the forums before
> upgrading each package is not practical. Similarly, the build logs are
> 99% stuff I don't care to read and 1% that I really do. How to find it?
> Better yet, I'd like to see it *before* I build.
Mommy, mommy! I found another project! It involves lots of cool parsing stuff!
That's nice dear...
I'm going to do this because
a) I like challenges
b) I already have the framework setup for it
Chris White
Kevin F. Quinn
> [...] To be more concrete, I'm thinking of something like a database [...]
I don't think a separate database is a good idea; too many sources for information.
> [...] For example [...]
> current: any
> target: =gnome-base/gnome-menus-2.10.0
> advisory: Menu editing disabled until follow-up release.
> Work-around is to install Python 4 + smeg. See
> forum topic http://forums.gentoo.org/blah...
How about adding:
ADVICE="Menu editing disabled until follow-up release.
Work-around is to install Python 4 + smeg. See
forum topic http://forums.gentoo.org/blah..."
to the gnome-menus-2.10.0 ebuild (sorry Chris, no parsing needed :} ). It'd be trivial to knock up a widget to extract and display this data, and I'd guess trivial to add an '--advice' option to emerge to do the same. Perhaps it'd be simpler just to include it alongside the changelog data with the '--changelog' option.
Of course such advice could be just written into the changelog in the first place...
Kev.
--
gento...@gentoo.org mailing list
Robin H. Johnson
> On 14/7/2005 7:24:03, Craig Lawson (craig....@alum.mit.edu) wrote:
> > [...] To be more concrete, I'm thinking of something like a database [...]
> I don't think a separate database is a good idea; too many sources for information.
it. It's metadata about the package, and it's already distributed with
the tree.
> > [...] For example [...]
> > current: any
> > target: =gnome-base/gnome-menus-2.10.0
> > advisory: Menu editing disabled until follow-up release.
> > Work-around is to install Python 4 + smeg. See
> > forum topic http://forums.gentoo.org/blah...
>
> How about adding:
>
> ADVICE="Menu editing disabled until follow-up release.
> Work-around is to install Python 4 + smeg. See
> forum topic http://forums.gentoo.org/blah..."
>
> to the gnome-menus-2.10.0 ebuild (sorry Chris, no parsing needed :} ).
> It'd be trivial to knock up a widget to extract and display this data,
> and I'd guess trivial to add an '--advice' option to emerge to do the
> same. Perhaps it'd be simpler just to include it alongside the
> changelog data with the '--changelog' option.
Putting it in the ebuild becomes a bit complex when you want to include
lots of text, or if you want to display a message for a specific
downgrade or something else like that. Basically while you have the
'target' attribute, you have no way to specify the 'current' attribute,
and you can't have multiple advisories per ebuild.
metadata.xml variant:
<pkgmetadata><advisory target="=gnome-base/gnome-menus-2.10.0">
Menu editing disabled until follow-up release.
Work-around is to install Python 4 + smeg. See
forum topic http://forums.gentoo.org/blah...
</advisory></pkgmetadata>
('current' attribute defaulting to any version, and both the 'target'
and 'current' attributes should be full package atoms.)
> Of course such advice could be just written into the changelog in the first place...
The problem is that users complain and don't read the changelog, since
it's too long. They want only specific advisories that are needed, not
every little change notice.
--
Robin Hugh Johnson
E-Mail : rob...@orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Georgi Georgiev
Since the changelog was mentioned, and since there is already a
--changelog switch (that I don't use because of the above-stated
reason), maybe some changelog entries could be marked as having a higher
priority (somehow reminds me of einfo and ewarn). If it were possible to
omit the "info" level entries and only show the important stuff from the
changelog with --changelog it would have been really useful.
emerge --changelog=warn ;)
There is no need for "current" or "target" either, since --changelog
already does the parsing.
--
*> Georgi Georgiev *> An age is called Dark not because the *>
<* ch...@gg3.net <* light fails to shine, but because people <*
*> +81(90)2877-8845 *> refuse to see it. -- James Michener, *>
<* ------------------- <* "Space" <*
R Hill
> 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
--
gento...@gentoo.org mailing list
Alec Warner
Hash: SHA1
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-----
--
gento...@gentoo.org mailing list
Jason Stubbs
> 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?
--
Jason Stubbs
Georgi Georgiev
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? \/
/\ ch...@gg3.net /\ /\
\/ +81(90)2877-8845 \/ \/
Alec Warner
Hash: SHA1
Georgi Georgiev wrote:
> 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.
Heh, I was attempting to combine your two suggestions in a good way and
failed. This sounds much better ;)
>>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.
>
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQuJZ22zglR5RwbyYAQKoQRAAkvXkNNNBA63jlqhN55v8JfHtcKJ747Qa
HsGHYmdVC++tegfPYGYFW5TTHaaGiePYeK2NTqbjODFPpb/uMP4+ZP6XPRT19vNC
2ruK4tChPnpsKu9vyKaRFOd/oDOmryuX8zUrzVfBUPr+P5BUuv2fVOZegrqF31ej
USO7WFpriEZ6Bv8QEbPQlj/cqyOMKdicFoU/iBSA69cX3ZJfBNbyabkaebaIyxAs
c4o3+21hBYfXG/JLPDO9S83xLTQhLWArR2HpeezuWwJMa+IJ5fGtLIN7pmbmuUvN
ZYwtl+kWigJEBlD99xGolJ6/aw5cN3A9/FZ2qhH70xfy43KvJA4qHsQld3vr6R/D
lBCl1v21sBbKkEUByM3TdcNu9f2EeGeMf+GFRDgZxfADNdCwWjqH7jPhgLwJKpFa
s9m+7ZRqrBiANp7M5nvVcD7lYkk5yCpmW3fjo2gsP0oKlXZrV0LXMuChIVscqkzK
iol0zs5rU0h7ywcG6FfhzqBUKB8s/hTyV0o/oaD8pxr5Wxkvgzl146MrHsYRvTXG
Jngi175osu+BsdrCP+0bbZdXosKGvaDhEBcpqDgIkW2O3iDHJHhf/BFMm2wjZZsy
CYSavpVm/p9sWMTiuWCLjxebXLn0xHpXdhKLB0fO1QbdxThn85MTdwptc8PAUcJf
u3RczNQLdgE=
=TTlc
Greg KH
> 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
--
gento...@gentoo.org mailing list
Jason Stubbs
> 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
Martin Schlemmer
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
Georgi Georgiev
So,
if $(has_version "<sys-fs/udev-046"); then
ewarn
fi
...
if $(has_version "<sys-fs/udev-059"); then
ewarn
fi
For gaim maybe something like this:
+if ! $(has_version "~${PV}" ); then
ewarn
- ewarn "If you are merging ${P} from an earlier version, you may need"
- ewarn "to re-merge any plugins like gaim-encryption or gaim-snpp."
+ ewarn "You may need to re-merge any plugins like gaim-encryption or gaim-snpp."
Maybe a function in an eclass can make this easier on people?
if $(package_is "<" 046); then
...
and package_is (name derived from kernel_is, don't flame the name, it is
for illustration only) could be something like this:
package_is() {
return $(has_version "${1}${CATEGORY}/${PN}-${2}")
}
That should be good enough for all packages, right?
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?
--
() Georgi Georgiev () Who is D.B. Cooper, and where is he now? ()
() ch...@gg3.net () ()
() +81(90)2877-8845 () ()
Jason Stubbs
> 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