From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, RDNS_NONE autolearn=no autolearn_force=no version=4.0.0 Received: from crunch.banyandesign.com (unknown [209.12.56.114]) by chiba.3jane.net (Postfix) with ESMTP id 3EDEBAC38C for ; Thu, 18 Apr 2002 20:06:11 -0500 (CDT) Received: from gentoo.org (adsl-78-163-176.gnv.bellsouth.net [216.78.163.176]) by crunch.banyandesign.com (8.10.0/8.10.0) with ESMTP id g3J0sjE11351 for ; Thu, 18 Apr 2002 20:54:48 -0400 Message-ID: <3CBF6D71.60101@gentoo.org> Date: Thu, 18 Apr 2002 21:05:53 -0400 From: William McArthur User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020413 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] System stability - update.mask Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 4dc67f4f-88cd-4caf-a432-ca1ab3162ef0 X-Archives-Hash: d56202a8757e073aa71b8f4a38b39db5 The following is some thoughts on how to provide the stability that I think most users really want while keeping the bleeding edge ones happy. This was promped by the IRC discussion I posted to the list earlier today. The problem with a stability metric on each pacakge as described in the channel is it doesn't describe the stability of the interaction of the packages between each other. It would not have solved the libpng problems many users had. Becuase I'm sure libpng-1.2.* is a solid package and each other package that linked against libpng-1.0.* would have had a reasonable stability metric from it's use before libpng-1.2.* was released. What I think would work well is a checkpoint system where every other month or so we have a package freeze for about a week or less. Then what I call a update.mask is generated based on the newest versions of all working packages out there. I originally thought of checkpoints as milestones like the mozilla guys use but a milestone is a goal, this is more like a saved state in a game. This update.mask is a lot like the package.mask in format but instead of disabling packages it defines a leading edge of packages that are not `emerge --update world` past. Kinda like drawing a line in the sand and saying all packages on one side of the line are reasonably tested to work well together. If the user wants to he can explictly emerge a package that is on the other side of that line but it would require him to type the version he wants. Also, I think this would obsolete the "world favorites" list that is maintained for a system. As I understand this feature it is to prevent the endless recompiling of point release of dependicies. I envision an option added to emerge that is like the `java-config --list-available-vms` but it would be `emerge --list-available-checkpoints`. The user can then select the desired checkpoint with something like `emerge --set-checkpoint gentoo-YYYY-MM` which then updated a symlink or something to the selected update.mask file. Also it would be nice to have a bleeding edge update.mask that doens't draw any leading edge. One thing I haven't figured out is how to deal with new packages added after the update.mask. The update.mask wouldn't know about the new package and I think updating old check points should be advoided. Suggestions welcome. Feed back welcomed. Sandy McArthur