From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DATE_IN_PAST_12_24, INVALID_DATE,MAILING_LIST_MULTI,NO_RELAYS autolearn=no autolearn_force=no version=4.0.0 Received: from drobbins by cvs.gentoo.org with local (Exim 3.22 #1) id 14oSmQ-0006wT-00 for gentoo-dev@gentoo.org; Sat, 14 Apr 2001 10:20:10 -0600 From: Daniel Robbins To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] package.mask Message-ID: <20010414102010.B25655@cvs.gentoo.org> References: <20010413151846.A6982@cvs.gentoo.org> <3AD864AC.F157EDCD@gentoo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AD864AC.F157EDCD@gentoo.org>; from AGottinger@t-online.de on Sat, Apr 14, 2001 at 04:54:36PM +0200 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Sat Apr 14 10:21:02 2001 X-Original-Date: Sat, 14 Apr 2001 10:20:10 -0600 X-Archives-Salt: 975e45eb-0294-448e-8a12-3513da3e00d7 X-Archives-Hash: ad86dbc669181654168b7ec7f036a0ae On Sat, Apr 14, 2001 at 04:54:36PM +0200, Achim Gottinger wrote: > Daniel, I have a question, why is it easier to add a new file (package.mask) > that excludes packages instead of using the already existing packages file > for masquerading (oposite of package.mask)? Good question... and here's a (hopefully) good answer. Consider what will happen when we have 20 different system-profiles on portage, and you add one experimental package to CVS. You could either add 20 lines to /usr/portage/profiles/[x]/packages, or add a single exclusion line to /usr/portage/profiles/package.mask. Remember that package.mask is shared by *every* profile, while the packages file is profile-specific. package.mask is specifically designed so that developers can exclude experimental ebuilds by adding one line to one file -- ebuilds that are not stable shouldn't be used under *any* profile. Now, CVS committers only need to modify a single file to "mask out" the broken ebuilds rather than carefully tweak every existing profile. This will allow for us to have certain people who are just "profile maintainers" -- maintaining a specific directory in /usr/portage/profiles -- but don't actually need to be up-to-date on which ebuilds are broken and which work this week or the next. That's the job of the ebuild maintainers, who keep /usr/portage/profiles/package.mask up-to-date to protect the profile maintainers and end-users. Lots of _underlines_ and *stars* around key words in the next paragraph just to make it easier to read.... The purpose of the packages file is to describe the _minimal_ ebuilds that should be installed under a *specific* profile, while package.mask describes the files that should _not_ be installed under *any* profile. Note that if a package is _not_ listed in packages, it *can* still be merged by the user. So, the packages file is _not_ supposed to prevent merging of not-listed packages, but rather require merging of packages (technically, satisfaction of dependencies) that *are* listed. For example, if you have a "minimal" profile, the packages file may only have 15 entries, but the user will still be able to merge GNOME if they choose to do so. The purpose of this design philosophy is to help ensure a working system without putting unnecessary restraints on the user. Apologies for not explaining this earlier; I thought you understood the concept behind the packages file. In any case, I hope you like the design -- personally, I think it's a good approach. While I still need to figure out how to resolve conflicts between package lines and the DEPEND/RDEPEND strings, this does not change the fact that the packages file was always intended (by me, at least) to list minimal-compliance requirements (dependencies) for a specific profile, rather than an exhaustive list of every possible package that is allowed to be installed like current-packages.new did. That's the concept behind a system profile -- to identify a subset of the packages on CVS that constitute a complete system. Best Regards, -- Daniel Robbins President/CEO http://www.gentoo.org Gentoo Technologies, Inc.