From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] New ebuild metadata to mark how robust the package is?
Date: Sat, 17 Oct 2009 09:53:39 +0200 [thread overview]
Message-ID: <200910170953.40078.patrick@gentoo.org> (raw)
In-Reply-To: <7486f8688d881f8d4a987199cb9ec8ea.squirrel@core-mail.net>
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 :)
next prev parent reply other threads:[~2009-10-17 7:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1255733421-30950-mlmmj-4f4db363@lists.gentoo.org>
2009-10-16 23:29 ` [gentoo-dev] New ebuild metadata to mark how robust the package is? Daniel Bradshaw
2009-10-16 23:48 ` Jeremy Olexa
2009-10-17 0:50 ` [gentoo-dev] " Ryan Hill
2009-10-17 5:33 ` [gentoo-dev] " Rémi Cardona
2009-10-17 9:27 ` Tobias Klausmann
2009-10-17 9:47 ` Petteri Räty
2009-10-17 7:53 ` Patrick Lauer [this message]
2009-10-18 0:10 ` [gentoo-dev] " Duncan
2009-10-21 12:45 ` Ladislav Laska
2009-10-21 15:21 ` Ladislav Laska
2009-10-21 16:30 ` William Hubbs
2009-10-26 12:55 ` Ladislav Laska
2009-10-26 21:49 ` Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200910170953.40078.patrick@gentoo.org \
--to=patrick@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox