From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21250 invoked from network); 5 Dec 2004 23:11:57 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 5 Dec 2004 23:11:57 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1Cb5Xp-0005Hs-2F for arch-gentoo-dev@lists.gentoo.org; Sun, 05 Dec 2004 23:11:57 +0000 Received: (qmail 21809 invoked by uid 89); 5 Dec 2004 23:11:56 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 8392 invoked from network); 5 Dec 2004 23:11:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Date: Sun, 05 Dec 2004 13:48:16 -0700 Organization: Sometimes Message-ID: References: <20041202193116.257eef32@snowdrop.home> <200412032332.14996.jstubbs@gentoo.org> <1102094351.4301.3.camel@localhost> <200412031748.57723.luke-jr@utopios.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-193.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news Subject: [gentoo-dev] Re: Identifying inherit-only / usable profiles X-Archives-Salt: fe110579-f66c-4d6f-88d8-0392114c1edb X-Archives-Hash: 9f84400407ac58847e8c52441471250f Ed Grimm posted , excerpted below, on Sun, 05 Dec 2004 21:59:17 +0000: > It seems to me that maintaining the valid list should be more > work than maintaining the invalid list, and if the reverse is true, > there is a problem in the way we are maintaining profiles. > > Semantics can be argued either way; I personally feel the unix return > code is the best metaphor - there's one success code, but many failure > codes. A profile can be supported, unsupported, deprecated, incomplete, > or broken. There's quite possibly a number of other states as well. FWIW, as a user... I like your error code metaphor, but would favor a single file with status, valid or form of invalid, with a specific error code if the file isn't there at all. The reasoning is this. One can never tell where a user is going to point the symlink. What if it points to /usr, for instance. Having a single status file allows portage a far more intelligent error than the current 'Is there a symlink at all and is it pointed to a valid location?' error. We can then have multiple error codes fitting the situation: 0/valid These would be various not a valid symlink errors 101/no /etc/make.profile symlink 102/file or dir, not symlink 103/symlink points to non-existent file/dir 104/symlink points to file, not dir 105/incomplete, no status file, is this a portage profile dir? 201/Status file present but profile incomplete due to lack of other info And the following warnings, overridable with an appropriate switch, for testing, or temp use of a a depreciated profile, for instance 501/masked as known-broken, unsupported 502/masked for testing, unsupported 503/masked as depreciated, unsupported, message points to recommended upgrade Of course, the error code numbers would be adjusted to fit portages current error code structure. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list