From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-dev+bounces-38041-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1MxO1a-00025p-Ii
	for garchives@archives.gentoo.org; Mon, 12 Oct 2009 16:45:30 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id F3844E0720;
	Mon, 12 Oct 2009 16:45:28 +0000 (UTC)
Received: from mail-fx0-f220.google.com (mail-fx0-f220.google.com [209.85.220.220])
	by pigeon.gentoo.org (Postfix) with ESMTP id 9D466E074E
	for <gentoo-dev@lists.gentoo.org>; Mon, 12 Oct 2009 16:45:28 +0000 (UTC)
Received: by fxm20 with SMTP id 20so8555610fxm.14
        for <gentoo-dev@lists.gentoo.org>; Mon, 12 Oct 2009 09:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=vhGvWwzvzVBNm0BHbkSeWfyRXVPJT3SQYqfKbcCCMHo=;
        b=HgEZkPuOnui5M6a/XKvb36SdZWHY5LT/VFXc/cG9fFGt4bHyKHZPhunkQdVk+15isd
         ebWY3x2bZaxgkISdDCtpoT+kBsputMczBwOmhIF7TwAuLM44VgxQwJY4HggATB/Eiv/Q
         jVivcIZpsYex8av64pJ/mcmdaKgCJmsPu377E=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=UHuRU4vJ1pyzZzkP4BtioMukyLmGxGYKR47YDDpRD6m6mxw3v7K5x/yDFdnYjWJXuG
         UXDmkRhLVRrUIyBD9nbyHn31B+Ue72//5DDTRT3RgDDkzMNlZXQMRJcXeycruXGvIUkQ
         v8e1Qng0gOWKp9kjtIJ0djl8g6GLbzElKzKyk=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.86.229.18 with SMTP id b18mr5443026fgh.34.1255365927899; Mon, 
	12 Oct 2009 09:45:27 -0700 (PDT)
In-Reply-To: <20091012093942.08ef453a@dante>
References: <20091012093942.08ef453a@dante>
Date: Mon, 12 Oct 2009 12:45:27 -0400
Message-ID: <deaa866a0910120945j2ebc3a35pa0cf197670e3f67e@mail.gmail.com>
Subject: Re: [gentoo-dev] Init systems portage category
From: Robert Bradbury <robert.bradbury@gmail.com>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=001485e9a6053213180475bfa8ed
X-Archives-Salt: a0967ee2-82dd-4bbe-a4aa-c98763b714ff
X-Archives-Hash: dcc34d80edee4b9b178cfc22853eed69

--001485e9a6053213180475bfa8ed
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 12, 2009 at 11:39 AM, Victor Ostorga <vostorga@gentoo.org>wrote:

>
> I don't know the history about init systems category, but obviously is
> necessary to stablish a category into which init systems should live
> happy forever (sys-init ? app-init? foobar?).
>
>
I don't know what you want to call it, "sys-init" perhaps.  But it, and a
number of other packages, e.g. sys-apps/util-linux (which includes mount and
fsck), openrc, bash, udev, etc. belong in a "special" category for "packages
which could prevent the system from booting or corrupt file systems" if the
emerges do not work perfectly.  I get hung up once or twice a year by
semi-auto-emerging a package not realizing that it is a potential
show-stopper that should be closely monitored (or which should require an
immediate system reboot to see if it broke anything).  In contrast, you
could break any of the various X libraries, browsers, etc. and still have a
system from which one could fall back/forward.

Right now one only knows if an emerge is "N"ew or an "U"pgrade with little
indication as to how badly it could go wrong.

As far as I know there is no "critical packages" list (or class) which
include those that are likely to create much bigger headaches than common
emerge failures (for example this would include all executables used by the
init/openrc processes) which under ideal circumstances would be part of a
single package that could be compiled with a "static" option.

Robert

--001485e9a6053213180475bfa8ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Mon, Oct 12, 2009 at 11:39 AM, Victor Ost=
orga <span dir=3D"ltr">&lt;<a href=3D"mailto:vostorga@gentoo.org">vostorga@=
gentoo.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p=
adding-left: 1ex;">
<br>
I don&#39;t know the history about init systems category, but obviously is<=
br>
necessary to stablish a category into which init systems should live<br>
happy forever (sys-init ? app-init? foobar?).<br>
<br>
</blockquote></div><br>I don&#39;t know what you want to call it, &quot;sys=
-init&quot; perhaps.=A0 But it, and a number of other packages, e.g. sys-ap=
ps/util-linux (which includes mount and fsck), openrc, bash, udev, etc. bel=
ong in a &quot;special&quot; category for &quot;packages which could preven=
t the system from booting or corrupt file systems&quot; if the emerges do n=
ot work perfectly.=A0 I get hung up once or twice a year by semi-auto-emerg=
ing a package not realizing that it is a potential show-stopper that should=
 be closely monitored (or which should require an immediate system reboot t=
o see if it broke anything).=A0 In contrast, you could break any of the var=
ious X libraries, browsers, etc. and still have a system from which one cou=
ld fall back/forward.<br>
<br>Right now one only knows if an emerge is &quot;N&quot;ew or an &quot;U&=
quot;pgrade with little indication as to how badly it could go wrong.<br><b=
r>As far as I know there is no &quot;critical packages&quot; list (or class=
) which include those that are likely to create much bigger headaches than =
common emerge failures (for example this would include all executables used=
 by the init/openrc processes) which under ideal circumstances would be par=
t of a single package that could be compiled with a &quot;static&quot; opti=
on.<br>
<br>Robert<br><br>

--001485e9a6053213180475bfa8ed--