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 ) id 1Mf6ds-0004KS-Id for garchives@archives.gentoo.org; Sun, 23 Aug 2009 06:33:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0318E0218; Sun, 23 Aug 2009 06:33:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 9A8E4E0218 for ; Sun, 23 Aug 2009 06:33:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3F0C864E1A for ; Sun, 23 Aug 2009 06:33:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 required=5.5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgVLZNqsImsY for ; Sun, 23 Aug 2009 06:33:19 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 738D666D8F for ; Sun, 23 Aug 2009 06:33:17 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1Mf6da-0005ED-Gp for gentoo-dev@gentoo.org; Sun, 23 Aug 2009 08:33:10 +0200 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Aug 2009 08:33:10 +0200 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Aug 2009 08:33:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: package.mask or package.mask.d Date: Sun, 23 Aug 2009 06:32:49 +0000 (UTC) Message-ID: References: <20090822205254.GA8975@linux1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9c4b78a3-ed28-4791-9a9c-72228971a508 X-Archives-Hash: abce88994b3e7fed419f4cde514dc694 William Hubbs posted on Sat, 22 Aug 2009 15:52:54 -0500 as excerpted: > On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote: >> We also need to consider whether people even want it done exactly the >> way Portage does it now. Some developers have expressed a preference >> for a package.mask.d of some kind instead. >=20 > I saw that, and I'm not sure why they suggested changing the directory > from package.mask to package.mask.d, since all you would need to do is > rename the file package.mask to something like package.mask/oldmasks an= d > the masks in it would be preserved until you put them in different file= s > in the package.mask directory and removed them from oldmasks, ultimatel= y > deleting oldmasks. The (one) idea is to keep package.mask as a file for old package managers= =20 that don't know about package.* as a directory yet. Moving package.mask=20 (the file) to package.mask/oldmasks wouldn't accomplish that. The=20 scenario people are worried about, is where (for example) someone has=20 gone away for their year's service (or two, or whatever) that some=20 nations have, and comes back and tries to upgrade, only to find the tree=20 is so changed that as soon as they sync, their old package manager is=20 broken, to the point they can't use use it to upgrade to a new version,=20 in ordered to be able to upgrade everything else! Actually splitting the current single file into multiple files isn't=20 really a problem, and would probably be done at the same time package.mas= k (.d) is made a directory, all in the same commit, so it's nothing to=20 worry about.=20 That said, in this particular instance, I don't believe that should be a=20 big problem. Why? Because portage has supported it for years already,=20 and anyone using a PM that doesn't currently support it has by definition= =20 already demonstrated they are reasonably active about their Gentoo based=20 system management choices, and thus isn't likely to let a system go=20 unsynced and the PM unupdated for greater than say 90 days anyway. Thus,= =20 when the policy is approved by council, stick a 90-180 day hold on=20 changing old profiles in the tree, and be done with it. So ancient PMs shouldn't be a problem either way, here. Which leaves=20 only a simple bikeshedding issue, whether people prefer keeping the names= =20 we have, or switching to the *.d forms in keeping with the pattern used=20 for all those /etc/*.d directories, of which a quick ls here demonstrated= =20 there's about double the number I expected, having never actually counted= =20 them before. While I'd vote for sticking with what we have, that /is/=20 just bikeshedding, and I REALLY want to just get on with it, regardless=20 of what it's named, as the feature really is quite useful. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman