From: Ryan Hill <dirtyepic@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: New ebuild metadata to mark how robust the package is?
Date: Fri, 16 Oct 2009 18:50:17 -0600 [thread overview]
Message-ID: <20091016185017.6193ee7b@gentoo.org> (raw)
In-Reply-To: 7486f8688d881f8d4a987199cb9ec8ea.squirrel@core-mail.net
[-- 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 --]
next prev parent reply other threads:[~2009-10-17 0:50 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 ` Ryan Hill [this message]
2009-10-17 5:33 ` 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
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=20091016185017.6193ee7b@gentoo.org \
--to=dirtyepic@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