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-38044-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1MxOuY-0005oI-Co
for garchives@archives.gentoo.org; Mon, 12 Oct 2009 17:42:18 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5FC2AE07DA;
Mon, 12 Oct 2009 17:42:17 +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 F1003E07DA
for <gentoo-dev@lists.gentoo.org>; Mon, 12 Oct 2009 17:42:16 +0000 (UTC)
Received: by fxm20 with SMTP id 20so8602605fxm.14
for <gentoo-dev@lists.gentoo.org>; Mon, 12 Oct 2009 10:42:16 -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=wJQo/1Fbi4DmLBX2gjv2uZ2Z+eNCUd+a8oSdimvsoT0=;
b=haeH595LptPcFlsIOgCy4l8lZutRanCzCFy3OvMdIi/9/nSSI23t1kuVoKgbOImFWs
9UTPheen5OSjqrNmlsmeyDNgog5NscA3rE6W45HvIWDVgNjvN9x9eEVVZG5rRTiOZYrQ
YrM9gaOq7b4fPAEW9nWteCeSpdNoi9VyOnShw=
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=JuotvCVhG2A5mAG+dj8g8+DAB2q9s4Z9fvDFeE9sit7EEwoUY9Yq8Cl9fYl3f0impd
c17nE7jUh2aHsLldiAflW090R+HWzh/DQYpmoluBLW3JfDSc+DWqsgU5ZdV/mfHAvmY/
hvrsuJp1M3xytIIP87TSnhN2jqeli0K+y608w=
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.208.2 with SMTP id f2mr5536901fgg.16.1255369336238; Mon, 12
Oct 2009 10:42:16 -0700 (PDT)
In-Reply-To: <173442fb4ce538d8895eb52554f0b780@localhost>
References: <20091012093942.08ef453a@dante>
<deaa866a0910120945j2ebc3a35pa0cf197670e3f67e@mail.gmail.com>
<173442fb4ce538d8895eb52554f0b780@localhost>
Date: Mon, 12 Oct 2009 13:42:16 -0400
Message-ID: <deaa866a0910121042r5314319dy13472f6799bddde6@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=00163600cb8e5935330475c0738c
X-Archives-Salt: 9385fe09-f2c6-4020-bcfe-bdb42fc537d5
X-Archives-Hash: 59738818d535fc548ec5e28d87cabc90
--00163600cb8e5935330475c0738c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
2009/10/12 Jes=FAs Guerrero <i92guboj@terra.es>
>
> But there's one... That what the "system" set is about in first place. We
> could argue if creating a new category would be any good or not, that's a
> different issue. But there's already a list of packages that's considered
> critical for a Gentoo system. That's what "system" is, and you will get a
> big red waning when trying to uninstall one package belonging to this
> category.
>
My point would be that the selection criteria isn't particularly
robust/strict. Iptunnel, df or du for example are not required to the best
of my knowledge for system booting or emerges. Dev-lang/python is on the
other hand required for emerging (and is not a "sys" package). I'm also no=
t
sure that the warnings are strict enough. In order to upgrade a package
(util-linux I think) recently I had to unmerge a library package on which i=
t
depended but which conflicted with an upgrade to said library. The unmerge
of the library package broke either fsck or mount (I can't remember which).
Had I tried to reboot before the upgrade was completed there would have bee=
n
problems.
Big "red warnings" are of no use when one is doing semi-automatic-upgrades
(and colored encodings are normally disabled when one dumps the emerge
output to a file). What is needed is a separate indicator in emerge output=
s
indicating that an upgrade is potentially "Dangerous" or should require
"Manual" intervention. Anyone who is not a full time developer but who
wants to maintain a relatively up-to-date Gentoo system (which IMO is its
primary advantage over "packaged" releases such as RedHat, Ubuntu, etc.) is
going to want to automate the nightly emerges as much as possible such that
no user intervention is required. And that probably works 90% of the time.
But there are those 5% of emerges that fail "reasonably" and require some
intervention (e.g. bug reports) and those 0.1-1% of emerges that fail (or
even succeed) with potential problems that could cost the user days. It is
that final category (and it isn't every binary produced by a sys* package)
that I am suggesting warrants more attention.
Robert
--00163600cb8e5935330475c0738c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">2009/10/12 Jes=FAs Guerrero <span dir=3D"ltr=
"><<a href=3D"mailto:i92guboj@terra.es">i92guboj@terra.es</a>></span>=
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class=3D"h5"><br>
</div></div>But there's one... That what the "system" set is =
about in first place. We<br>
could argue if creating a new category would be any good or not, that's=
a<br>
different issue. But there's already a list of packages that's cons=
idered<br>
critical for a Gentoo system. That's what "system" is, and yo=
u will get a<br>
big red waning when trying to uninstall one package belonging to this<br>
category.<br></blockquote><div><br>My point would be that the selection cri=
teria isn't particularly robust/strict.=A0 Iptunnel, df or du for examp=
le are not required to the best of my knowledge for system booting or emerg=
es.=A0 Dev-lang/python is on the other hand required for emerging (and is n=
ot a "sys" package).=A0 I'm also not sure that the warnings a=
re strict enough.=A0 In order to upgrade a package (util-linux I think) rec=
ently I had to unmerge a library package on which it depended but which con=
flicted with an upgrade to said library.=A0 The unmerge of the library pack=
age broke either fsck or mount (I can't remember which).=A0 Had I tried=
to reboot before the upgrade was completed there would have been problems.=
<br>
<br>Big "red warnings" are of no use when one is doing semi-autom=
atic-upgrades (and colored encodings are normally disabled when one dumps t=
he emerge output to a file).=A0 What is needed is a separate indicator in e=
merge outputs indicating that an upgrade is potentially "Dangerous&quo=
t; or should require "Manual" intervention.=A0 Anyone who is not =
a full time developer but who wants to maintain a relatively up-to-date Gen=
too system (which IMO is its primary advantage over "packaged" re=
leases such as RedHat, Ubuntu, etc.) is going to want to automate the night=
ly emerges as much as possible such that no user intervention is required.=
=A0 And that probably works 90% of the time.=A0 But there are those 5% of e=
merges that fail "reasonably" and require some intervention (e.g.=
bug reports) and those 0.1-1% of emerges that fail (or even succeed) with =
potential problems that could cost the user days.=A0 It is that final categ=
ory (and it isn't every binary produced by a sys* package) that I am su=
ggesting warrants more attention.<br>
<br>Robert<br><br></div></div><br>
--00163600cb8e5935330475c0738c--