[gentoo-dev] New ebuild metadata to mark how robust the package is?

[gentoo-dev] New ebuild metadata to mark how robust the package is?

[Daniel Bradshaw]

Hi all,

It occurs to me that my work flow when doing updates follows a fairly
predictable (and probably common) pattern.
The obvious next step is to wonder why no one though of automating it...

When doing updates I tend to look through the package list and classify
things based on how likely they are to break.
Some packages, like findutils, are pretty robust and generally just get on
with working.
Other packages, like apache and ssh, need are more fragile and need plenty
of configuration.

Packages from the second group want emerging on their own, or in small
groups, the better to keep an eye out for notices about things that might
break, to update configs, and to check that they're running happily.

Once the update list is reduced to packages from the first group it's
fairly safe to run emerge -u world and not worry about things exploding
too badly.


So as I say, it occurs to me that most people probably follow some
variation of this selective upgrade method.
It might be handy to have some kind of metadata in the ebuilds that can be
used to indicate a package that is "demanding".
Then that flag could be used to highlight the package on a dep tree, or
optionally to block the emerge unless the package is specified explicitly.

`emerge -vaut @safe` would be kinda useful.

Just a thought.

Regards,
Daniel

Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

[Jeremy Olexa]

Daniel Bradshaw wrote:
> Hi all,
> 
> It occurs to me that my work flow when doing updates follows a fairly
> predictable (and probably common) pattern.
> The obvious next step is to wonder why no one though of automating it...
> 
> When doing updates I tend to look through the package list and classify
> things based on how likely they are to break.
> Some packages, like findutils, are pretty robust and generally just get on
> with working.
> Other packages, like apache and ssh, need are more fragile and need plenty
> of configuration.
> 
> Packages from the second group want emerging on their own, or in small
> groups, the better to keep an eye out for notices about things that might
> break, to update configs, and to check that they're running happily.
> 
> Once the update list is reduced to packages from the first group it's
> fairly safe to run emerge -u world and not worry about things exploding
> too badly.
> 
> 
> So as I say, it occurs to me that most people probably follow some
> variation of this selective upgrade method.
> It might be handy to have some kind of metadata in the ebuilds that can be
> used to indicate a package that is "demanding".
> Then that flag could be used to highlight the package on a dep tree, or
> optionally to block the emerge unless the package is specified explicitly.
> 
> `emerge -vaut @safe` would be kinda useful.
> 
> Just a thought.
> 
> Regards,
> Daniel
> 

I am seeing a trend here because this email aligns with the thoughts on 
the openrc email thread a few days ago. That being said, no clue how to 
implement it. Actually I think that marking a package as "demanding" 
would be the more useful than "safe" because probably 95+% of packages 
are "safe"

But, as with a request for an indicator for compile times[1], I think 
this proposal would be a failure in general because of subjective 
opinions between people. I would consider apache/lighttpd as being 
"safe" after initial configuration as long as you don't automatically 
etc-update. But you or someone else would not think it was safe. 
Therefore, nice in theory but probably wouldn't work in practice.

Nice idea, keep them rolling and I'm not trying to kill the thread. :)

-Jeremy
[1]: http://bugs.gentoo.org/288193

[gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

On Fri, 16 Oct 2009 23:29:00 -0000 (UTC)
"Daniel Bradshaw" <daniel@the-cell.co.uk> wrote:

> Hi all,
> 
> It occurs to me that my work flow when doing updates follows a fairly
> predictable (and probably common) pattern.
> The obvious next step is to wonder why no one though of automating it...
> 
> When doing updates I tend to look through the package list and classify
> things based on how likely they are to break.
> Some packages, like findutils, are pretty robust and generally just get on
> with working.
> Other packages, like apache and ssh, need are more fragile and need plenty
> of configuration.
> 
> Packages from the second group want emerging on their own, or in small
> groups, the better to keep an eye out for notices about things that might
> break, to update configs, and to check that they're running happily.
> 
> Once the update list is reduced to packages from the first group it's
> fairly safe to run emerge -u world and not worry about things exploding
> too badly.
> 
> 
> So as I say, it occurs to me that most people probably follow some
> variation of this selective upgrade method.
> It might be handy to have some kind of metadata in the ebuilds that can be
> used to indicate a package that is "demanding".
> Then that flag could be used to highlight the package on a dep tree, or
> optionally to block the emerge unless the package is specified explicitly.
> 
> `emerge -vaut @safe` would be kinda useful.
> 
> Just a thought.

As Jeremy said this is really subjective.  I think what might be a more
reasonable thing to ask for is a way to mark particular upgrades as
potentially troublesome.  Personally I just alias e='emerge -avl' and pay
attention to the changelogs.


-- 
fonts,                             Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

[Rémi Cardona]

Hi Daniel,

Le 17/10/2009 01:29, Daniel Bradshaw a écrit :
> So as I say, it occurs to me that most people probably follow some
> variation of this selective upgrade method.
> It might be handy to have some kind of metadata in the ebuilds that can be
> used to indicate a package that is "demanding".
> Then that flag could be used to highlight the package on a dep tree, or
> optionally to block the emerge unless the package is specified explicitly.

IMHO, we already have the infrastructure for such info. We have elog and 
news items.

Now we (gentoo devs) are finally starting to add news items for bigger 
updates (gnome, X, java, etc) and that's a good thing. But we definitely 
cannot and should not use news items for minor upgrades.

elog is much better suited for such upgrade notices.

However, since elog was put in portage, ebuilds have been using 
elog/ewarn/einfo _way_ too much. We're now at a point where the elog 
output at the end of an emerge phase is just _useless_ because of all 
the noise.

And with your metadata proposal, I'm worried the same thing will happen. 
Devs will enable the "troublesome" flag for a release, forget to remove 
it for the next bump and a few months later, half the packages in 
portage are labeled as such.

I really don't want to sound like I want to kill your idea but I'm 
somewhat doubtful it'll really work given our track record with other 
such infrastructure.

Cheers :)

Rémi

Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

[Patrick Lauer]

On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote:
> Some packages, like findutils, are pretty robust and generally just get on
> with working.
> Other packages, like apache and ssh, need are more fragile and need plenty
> of configuration.
That's almost completely user-side configuration outside the influence of 
portage. emerge findutils and emerge apache "works" the same ...

 
> Packages from the second group want emerging on their own, or in small
> groups, the better to keep an eye out for notices about things that might
> break, to update configs, and to check that they're running happily.
That's a very individual thing :) 
Sometimes apache is a critical service, sometimes apache is just there as a 
fallback if/when the lighttpd+php+... stack breaks.

> Once the update list is reduced to packages from the first group it's
> fairly safe to run emerge -u world and not worry about things exploding
> too badly.
> 
> 
> So as I say, it occurs to me that most people probably follow some
> variation of this selective upgrade method.
> It might be handy to have some kind of metadata in the ebuilds that can be
> used to indicate a package that is "demanding".
There's one issue with that - library updates and compiler updates and all 
those other variations. I had a funky crashbug in amule for a while that, as 
far as I can tell, is a mix of a confused crypto lib, wxGTK and amule itself 
not agreeing much. It disappeared with the last updates, and it would only 
trigger in this constellation.

So what might work perfectly for most people could still violently explode for 
you. We already try to tag things with KEYWORDS - while that isn't the best 
indicator it gives you a general idea that ~arch is a bit less predictable 
than arch. And if it comes from an overlay you're on your own anyway. Why add 
just another level of labelling to that?

From my point of view that's just adding more noise instead of fixing the 
problem (package quality and interaction bugs). But that would take lots of 
time, lots of motivated people and will never stop :)

Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

[Tobias Klausmann]

Hi! 

On Sat, 17 Oct 2009, Rémi Cardona wrote:
> Now we (gentoo devs) are finally starting to add news items for
> bigger updates (gnome, X, java, etc) and that's a good thing.
> But we definitely cannot and should not use news items for
> minor upgrades.
> 
> elog is much better suited for such upgrade notices.
> 
> However, since elog was put in portage, ebuilds have been using
> elog/ewarn/einfo _way_ too much. We're now at a point where the
> elog output at the end of an emerge phase is just _useless_
> because of all the noise.

One problem with this is that there is no way to "Acknowledge"
such ewarns/einfos. For example, I really, honestly know that
vanilla-sources isn't supported; I don't need the reminder every
time I upgrade it. Neither does the message from gentoo-sources
help me in any way anymore.

Come to think of it, how about an ewarn/einfo that is only
triggered on fresh installs, but not on upgrades? You can still
warn that foobard needs an etc-update and a restart, but I don't
need to be reminded where the examples are every time.

Ideally, one would be an einfo and one an ewarn, but in my
experience, many messages are ewarns "to be safe" (or so I
suspect).

> And with your metadata proposal, I'm worried the same thing
> will happen. Devs will enable the "troublesome" flag for a
> release, forget to remove it for the next bump and a few months
> later, half the packages in portage are labeled as such.
> 
> I really don't want to sound like I want to kill your idea but
> I'm somewhat doubtful it'll really work given our track record
> with other such infrastructure.

As usual with such things, it should as simple as possible to
use, especially when only bumping a package (hence my idea of
separate "one-shot" message functions).


Regards,
Tobias
-- 
printk ("Barf\n");
        linux-2.6.6/arch/v850/kernel/module.c

Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Tobias Klausmann wrote:
> 
> Come to think of it, how about an ewarn/einfo that is only
> triggered on fresh installs, but not on upgrades? You can still
> warn that foobard needs an etc-update and a restart, but I don't
> need to be reminded where the examples are every time.
> 
> Ideally, one would be an einfo and one an ewarn, but in my
> experience, many messages are ewarns "to be safe" (or so I
> suspect).
> 

With EAPI 3 easy to add wrappers around e* using REPLACING_VERSIONS and
REPLACED_BY_VERSION.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[Duncan]

Patrick Lauer posted on Sat, 17 Oct 2009 09:53:39 +0200 as excerpted:

> On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote:
>> Some packages, like findutils, are pretty robust and generally just get
>> on with working.
>> Other packages, like apache and ssh, need are more fragile and need
>> plenty of configuration.
> That's almost completely user-side configuration outside the influence
> of portage. emerge findutils and emerge apache "works" the same ...
> 
> 
>> Packages from the second group want emerging on their own, or in small
>> groups, the better to keep an eye out for notices about things that
>> might break, to update configs, and to check that they're running
>> happily.
> That's a very individual thing :)
> Sometimes apache is a critical service, sometimes apache is just there
> as a fallback if/when the lighttpd+php+... stack breaks.

FWIW, there's a portage helper package, IDR the name as I have my own 
system for this but it looks like it might be helpful here, that allows 
users to pick and choose their updates.  One could run it multiple times, 
updating (what the user considers) the critical stuff on its own, and 
updating everything else in a big bunch.

That seems like the answer here; it already exists; and it's in the tree 
(unless it has been removed recently, I don't know as IDR the name).  
Take a look thru app-portage and see what you find.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[Ladislav Laska]

Hi,

One can see some similarity to a thread around week or two old (about
critical packages). I would imagine, that a simple and straightforward
solution would be to make a new set of packages. Since we already have
world and system sets, it wouldn't hurt to have a third, "safe" list
which would be configurable by user. What I mean is:

I consider ssh, postfix two very important packages (ssh is pretty
stable, but hey, what if...) and I would most certainly not want to
trigger emerge world and not notice postfix. So: I would add ssh and
postfix to the "safe" set and do emerge -avu @safe, have a coffee and
looked whether it's ok (mail are flowing, can login, etc. etc.) and
then do emerge -avuD world and sleep well.

I think this would be good solution for all of you?


Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Sun, Oct 18, 2009 at 2:10 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Patrick Lauer posted on Sat, 17 Oct 2009 09:53:39 +0200 as excerpted:
>
>> On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote:
>>> Some packages, like findutils, are pretty robust and generally just get
>>> on with working.
>>> Other packages, like apache and ssh, need are more fragile and need
>>> plenty of configuration.
>> That's almost completely user-side configuration outside the influence
>> of portage. emerge findutils and emerge apache "works" the same ...
>>
>>
>>> Packages from the second group want emerging on their own, or in small
>>> groups, the better to keep an eye out for notices about things that
>>> might break, to update configs, and to check that they're running
>>> happily.
>> That's a very individual thing :)
>> Sometimes apache is a critical service, sometimes apache is just there
>> as a fallback if/when the lighttpd+php+... stack breaks.
>
> FWIW, there's a portage helper package, IDR the name as I have my own
> system for this but it looks like it might be helpful here, that allows
> users to pick and choose their updates.  One could run it multiple times,
> updating (what the user considers) the critical stuff on its own, and
> updating everything else in a big bunch.
>
> That seems like the answer here; it already exists; and it's in the tree
> (unless it has been removed recently, I don't know as IDR the name).
> Take a look thru app-portage and see what you find.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
>

Re: [gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[Ladislav Laska]

Of course, by "safe" I meant "unsafe" or "needs-additional-care" or
whatever,... My bad.

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Wed, Oct 21, 2009 at 12:45 PM, Ladislav Laska
<ladislav.laska@gmail.com> wrote:
> Hi,
>
> One can see some similarity to a thread around week or two old (about
> critical packages). I would imagine, that a simple and straightforward
> solution would be to make a new set of packages. Since we already have
> world and system sets, it wouldn't hurt to have a third, "safe" list
> which would be configurable by user. What I mean is:
>
> I consider ssh, postfix two very important packages (ssh is pretty
> stable, but hey, what if...) and I would most certainly not want to
> trigger emerge world and not notice postfix. So: I would add ssh and
> postfix to the "safe" set and do emerge -avu @safe, have a coffee and
> looked whether it's ok (mail are flowing, can login, etc. etc.) and
> then do emerge -avuD world and sleep well.
>
> I think this would be good solution for all of you?
>
>
> Regards Ladislav Laska
> S pozdravem Ladislav Laska
> ---
> xmpp/jabber: ladislav.laska@jabber.cz
>
>
>
> On Sun, Oct 18, 2009 at 2:10 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Patrick Lauer posted on Sat, 17 Oct 2009 09:53:39 +0200 as excerpted:
>>
>>> On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote:
>>>> Some packages, like findutils, are pretty robust and generally just get
>>>> on with working.
>>>> Other packages, like apache and ssh, need are more fragile and need
>>>> plenty of configuration.
>>> That's almost completely user-side configuration outside the influence
>>> of portage. emerge findutils and emerge apache "works" the same ...
>>>
>>>
>>>> Packages from the second group want emerging on their own, or in small
>>>> groups, the better to keep an eye out for notices about things that
>>>> might break, to update configs, and to check that they're running
>>>> happily.
>>> That's a very individual thing :)
>>> Sometimes apache is a critical service, sometimes apache is just there
>>> as a fallback if/when the lighttpd+php+... stack breaks.
>>
>> FWIW, there's a portage helper package, IDR the name as I have my own
>> system for this but it looks like it might be helpful here, that allows
>> users to pick and choose their updates.  One could run it multiple times,
>> updating (what the user considers) the critical stuff on its own, and
>> updating everything else in a big bunch.
>>
>> That seems like the answer here; it already exists; and it's in the tree
>> (unless it has been removed recently, I don't know as IDR the name).
>> Take a look thru app-portage and see what you find.
>>
>> --
>> Duncan - List replies preferred.   No HTML msgs.
>> "Every nonfree program has a lord, a master --
>> and if you use the program, he is your master."  Richard Stallman
>>
>>
>>
>

Re: [gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3630 bytes --]

Afaik, you can already do this.

Make a file in /etc/portage/sets/critical, or whatever you want to call
it, and in there list the packages you are concerned about.

Then you can do:

emerge -NDup @critical

to see the packages in that set that need to be upgraded or you can use
@critical in any other place you could use a set.

William

On Wed, Oct 21, 2009 at 03:21:34PM +0000, Ladislav Laska wrote:
> Of course, by "safe" I meant "unsafe" or "needs-additional-care" or
> whatever,... My bad.
> 
> Regards Ladislav Laska
> S pozdravem Ladislav Laska
> ---
> xmpp/jabber: ladislav.laska@jabber.cz
> 
> 
> 
> On Wed, Oct 21, 2009 at 12:45 PM, Ladislav Laska
> <ladislav.laska@gmail.com> wrote:
> > Hi,
> >
> > One can see some similarity to a thread around week or two old (about
> > critical packages). I would imagine, that a simple and straightforward
> > solution would be to make a new set of packages. Since we already have
> > world and system sets, it wouldn't hurt to have a third, "safe" list
> > which would be configurable by user. What I mean is:
> >
> > I consider ssh, postfix two very important packages (ssh is pretty
> > stable, but hey, what if...) and I would most certainly not want to
> > trigger emerge world and not notice postfix. So: I would add ssh and
> > postfix to the "safe" set and do emerge -avu @safe, have a coffee and
> > looked whether it's ok (mail are flowing, can login, etc. etc.) and
> > then do emerge -avuD world and sleep well.
> >
> > I think this would be good solution for all of you?
> >
> >
> > Regards Ladislav Laska
> > S pozdravem Ladislav Laska
> > ---
> > xmpp/jabber: ladislav.laska@jabber.cz
> >
> >
> >
> > On Sun, Oct 18, 2009 at 2:10 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> >> Patrick Lauer posted on Sat, 17 Oct 2009 09:53:39 +0200 as excerpted:
> >>
> >>> On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote:
> >>>> Some packages, like findutils, are pretty robust and generally just get
> >>>> on with working.
> >>>> Other packages, like apache and ssh, need are more fragile and need
> >>>> plenty of configuration.
> >>> That's almost completely user-side configuration outside the influence
> >>> of portage. emerge findutils and emerge apache "works" the same ...
> >>>
> >>>
> >>>> Packages from the second group want emerging on their own, or in small
> >>>> groups, the better to keep an eye out for notices about things that
> >>>> might break, to update configs, and to check that they're running
> >>>> happily.
> >>> That's a very individual thing :)
> >>> Sometimes apache is a critical service, sometimes apache is just there
> >>> as a fallback if/when the lighttpd+php+... stack breaks.
> >>
> >> FWIW, there's a portage helper package, IDR the name as I have my own
> >> system for this but it looks like it might be helpful here, that allows
> >> users to pick and choose their updates. ??One could run it multiple times,
> >> updating (what the user considers) the critical stuff on its own, and
> >> updating everything else in a big bunch.
> >>
> >> That seems like the answer here; it already exists; and it's in the tree
> >> (unless it has been removed recently, I don't know as IDR the name).
> >> Take a look thru app-portage and see what you find.
> >>
> >> --
> >> Duncan - List replies preferred. ?? No HTML msgs.
> >> "Every nonfree program has a lord, a master --
> >> and if you use the program, he is your master." ??Richard Stallman
> >>
> >>
> >>
> >
> 

-- 
William Hubbs
gentoo accessibility team lead
williamh@gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[Ladislav Laska]

This is awesome! It really like the idea, but (there is always "but",
right?) it doesn't work.

I have googled for it for a while and haven't found any reference how
to do it exactly.

I have created mentioned file and run emerge, but I've got

$ sudo emerge -av @critical
!!! '@critical' is not a valid package atom.
!!! Please check ebuild(5) for full details

And I have no idea why. Also, I'm using portage 2.1.7.1. I guess this
is new feature in 2.2?

Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska@jabber.cz



On Wed, Oct 21, 2009 at 5:30 PM, William Hubbs <williamh@gentoo.org> wrote:
> Afaik, you can already do this.
>
> Make a file in /etc/portage/sets/critical, or whatever you want to call
> it, and in there list the packages you are concerned about.
>
> Then you can do:
>
> emerge -NDup @critical
>
> to see the packages in that set that need to be upgraded or you can use
> @critical in any other place you could use a set.
>
> William
>
> On Wed, Oct 21, 2009 at 03:21:34PM +0000, Ladislav Laska wrote:
>> Of course, by "safe" I meant "unsafe" or "needs-additional-care" or
>> whatever,... My bad.
>>
>> Regards Ladislav Laska
>> S pozdravem Ladislav Laska
>> ---
>> xmpp/jabber: ladislav.laska@jabber.cz
>>
>>
>>
>> On Wed, Oct 21, 2009 at 12:45 PM, Ladislav Laska
>> <ladislav.laska@gmail.com> wrote:
>> > Hi,
>> >
>> > One can see some similarity to a thread around week or two old (about
>> > critical packages). I would imagine, that a simple and straightforward
>> > solution would be to make a new set of packages. Since we already have
>> > world and system sets, it wouldn't hurt to have a third, "safe" list
>> > which would be configurable by user. What I mean is:
>> >
>> > I consider ssh, postfix two very important packages (ssh is pretty
>> > stable, but hey, what if...) and I would most certainly not want to
>> > trigger emerge world and not notice postfix. So: I would add ssh and
>> > postfix to the "safe" set and do emerge -avu @safe, have a coffee and
>> > looked whether it's ok (mail are flowing, can login, etc. etc.) and
>> > then do emerge -avuD world and sleep well.
>> >
>> > I think this would be good solution for all of you?
>> >
>> >
>> > Regards Ladislav Laska
>> > S pozdravem Ladislav Laska
>> > ---
>> > xmpp/jabber: ladislav.laska@jabber.cz
>> >
>> >
>> >
>> > On Sun, Oct 18, 2009 at 2:10 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> >> Patrick Lauer posted on Sat, 17 Oct 2009 09:53:39 +0200 as excerpted:
>> >>
>> >>> On Saturday 17 October 2009 01:29:00 Daniel Bradshaw wrote:
>> >>>> Some packages, like findutils, are pretty robust and generally just get
>> >>>> on with working.
>> >>>> Other packages, like apache and ssh, need are more fragile and need
>> >>>> plenty of configuration.
>> >>> That's almost completely user-side configuration outside the influence
>> >>> of portage. emerge findutils and emerge apache "works" the same ...
>> >>>
>> >>>
>> >>>> Packages from the second group want emerging on their own, or in small
>> >>>> groups, the better to keep an eye out for notices about things that
>> >>>> might break, to update configs, and to check that they're running
>> >>>> happily.
>> >>> That's a very individual thing :)
>> >>> Sometimes apache is a critical service, sometimes apache is just there
>> >>> as a fallback if/when the lighttpd+php+... stack breaks.
>> >>
>> >> FWIW, there's a portage helper package, IDR the name as I have my own
>> >> system for this but it looks like it might be helpful here, that allows
>> >> users to pick and choose their updates. ??One could run it multiple times,
>> >> updating (what the user considers) the critical stuff on its own, and
>> >> updating everything else in a big bunch.
>> >>
>> >> That seems like the answer here; it already exists; and it's in the tree
>> >> (unless it has been removed recently, I don't know as IDR the name).
>> >> Take a look thru app-portage and see what you find.
>> >>
>> >> --
>> >> Duncan - List replies preferred. ?? No HTML msgs.
>> >> "Every nonfree program has a lord, a master --
>> >> and if you use the program, he is your master." ??Richard Stallman
>> >>
>> >>
>> >>
>> >
>>
>
> --
> William Hubbs
> gentoo accessibility team lead
> williamh@gentoo.org
>

[gentoo-dev] Re: New ebuild metadata to mark how robust the package is?

[Duncan]

Ladislav Laska posted on Mon, 26 Oct 2009 13:55:51 +0100 as excerpted:

> I have created mentioned file and run emerge, but I've got
> 
> $ sudo emerge -av @critical
> !!! '@critical' is not a valid package atom. !!! Please check ebuild(5)
> for full details
> 
> And I have no idea why. Also, I'm using portage 2.1.7.1. I guess this is
> new feature in 2.2?

Yes.  Sets were left for 2.2, as the implementation wasn't quite ready 
for 2.1 stability.  (As I understand it, there's multiple set 
implementations, and before sets become available as in-tree kde install 
options, for instance, they needed some reconciliation and possible PMS/
EAPI approval.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman