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 :)