Re: [gentoo-dev] Re: Proposal: pre-emerge advisories
-BEGIN PGP SIGNED MESSAGE-
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
-END PGP SIGNATURE-
--
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] QA feedback
Chris Gianelloni wrote:
> On Wed, 2005-07-20 at 01:43 -0400, Mike Frysinger wrote:
>
>>>This sounds like a request for the QA team. I tend to stay away
>>>from most ~arch packages simply because most of our systems are
>>>live production servers, but I'd be happy to test-drive new ebuilds
>>>of vpopmail if it would help get new versions into the stable tree
>>>faster.
>>
>>maybe ... but i think more than just the QA team needs to brainstorm some
>>sort
>>of feedback system ...
>
>
> We *had* stable.gentoo.org, but I don't think anybody really used it and
> I'm not sure the output actually went to anyone. Perhaps now that we
> have metadata.xml and a defined place for these to go to, we could
> revive something similar?
>
> Something like a little check box that means "WORKSFORME" on a
> particular ebuild/arch.
Actually, with the Gentoo/MIPS project... we've got a (semi-unofficial)
hardware compatability database, where people can specify what
configurations work for them, etc.
http://stuartl.longlandclan.hopto.org/gentoo/mips/
Basically, the above site, allows people to record what configurations
work for them, as well as the kernel configs used. They can make their
own notes as to how this configuration runs. It also works in reverse,
if I were to get an O2, I could go to that site, and have my pick of 3
(at time of writing) kernel configurations that I could try, two 2.6.9,
one 2.6.12-rc2.
Perhaps something for packages could be rigged up? I would certainly
make use of such a system if one existed. If anyone's interested (in
particular, arch teams) in the code for the above site, I'm happy to
distribute it -- just needs PHP and MySQL.
--
_ Stuart Longland (a.k.a Redhatter)
/ _ \ ______ __| |__ __ __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ / \ ; \(__ __)/ \ / \Developer
\// O _| / /\ \ | | | /\ | /\ |
/ / \ /__| / \ \ | | | \/ | \/ |
(___/ \/|_; |_| \_/ \__/ \__/ http://dev.gentoo.org/~redhatter
signature.asc
Description: OpenPGP digital signature
