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 14oXa1-0000Gm-00 for gentoo-dev@gentoo.org; Sat, 14 Apr 2001 15:27:41 -0600 From: Daniel Robbins To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] package.mask Message-ID: <20010414152741.G25655@cvs.gentoo.org> References: <20010413151846.A6982@cvs.gentoo.org> <3AD864AC.F157EDCD@gentoo.org> <20010414102010.B25655@cvs.gentoo.org> <3AD88590.67EF0128@gentoo.org> <20010414121853.D25655@cvs.gentoo.org> <3AD892B2.C04083A8@gentoo.org> <20010414133428.F25655@cvs.gentoo.org> <3AD8ABF4.47F30206@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: <3AD8ABF4.47F30206@gentoo.org>; from AGottinger@t-online.de on Sat, Apr 14, 2001 at 09:58:44PM +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 15:28:02 2001 X-Original-Date: Sat, 14 Apr 2001 15:27:41 -0600 X-Archives-Salt: 53e0bff0-87f7-470a-811a-a47bc562729f X-Archives-Hash: 0e7d23c1ae225439061da3858e8a39b4 On Sat, Apr 14, 2001 at 09:58:44PM +0200, Achim Gottinger wrote: > > No, it isn't that complicated. > Did I miss some mathematical break thrus? Let us just focus on glibc, > ncurses and a package that requires both. Now assume we have 2 versions of > glibc and 2 of ncurses. So we must get the package working with 4 different > lib combinations. (no math study required for that example). We have a > maximum dependencie dept at about 10 for some gnome package. Assume 2 > possibilities for for each dep and you must run 2^10 tests for a single > package. Of cause it is not complicated to automate the tests, but it may > take a while to run them. OK, you are right -- we can't test every possible combination of packages with one another. Maybe I should have said this: every .ebuild on CVS should work on every Gentoo Linux system, as long as its DEPEND and RDEPEND variables can be and are satisifed. If this is not the case, the package should be listed in package.mask. So, if sys-apps/foo-1.0 requires sys-apps/bar-1.0, but there's an entry in your current profile that reads: !sys-apps/bar-1.0 Then, because of this entry, merging sys-apps/foo-1.0 will not be allowed on your system. I guess what I'm trying to say is this -- the features I'm talking about should allow us to create many "virtual systems", all from a single unbranched cvs repository. All we need to do is to make sure that the latest rev of working older ebuilds are kept for compatibility's sake, so that there is more than just the latest version of a particular .ebuild available. For example, keeping bash-2.04-r3.ebuild on CVS so that systems that aren't allowed to run bash-2.05 still have a valid bash shell ebuild. This should eliminate the need for branching our CVS tree. > No I ment !sys-apps/bash-2.04 in package.mask. Oh, ok. Right now, "!" deps are not allowed in package.mask, but I can make them work. The problem is that in DEPEND, "!sys-apps/bash-2.04" means "not sys-apps/bash-2.04", but in package.mask, it would have another meaning -- "any version of sys-apps/bash *but* 2.04". So I would need to tweak the code a bit to support this new use of the ! operator. =, >=, >, <, <= and no operator are currently supported. If needed, I can also get "foo? ( sys-apps/bar )"-type masks working. Right now, I'm using the python dep_match() function, which is designed for =,>=, etc, but not for ! or deps with multiple tokens (like "foo? ( bar )"). But I can use a more advanced dep function if needed. > > "ebuild" would still allow you to manually install a package if you absolutely > > wanted to -- we will begin considering ebuild a low-level developer's tool as > > emerge and pkgmerge become more feature-rich. > Wouldn't it be easier to use emerge for pkgmerge too. emerge can check if a > suitable tbz2-package exists for a required package and uses this instead of > building it. If you call emerge [package].tbz2, this packages .ebuild file is > used. Yes, I have plans to combine pkgmerge and emerge soon. First, I want to get package.mask and packages finalized. > But that whould break your first idea of the packages file. There's no harm in throwing away an idea that was already broken :) > How about using a global mask file to eliminate in development packages and a > profile depending to controll packages versions more efficient. In this > scenarion the packages file does only contain lines like sys-apps/bash > without any version information. Once we have a rc4 we can list all packages > with their versions in packages/rc4/package.mask with for example > =sys-apps/bash-2.05. If you want to keep all packages on your system up to > date, you can simply delete the profile depending package.mask file and can > still be sure you don't get unusable in development packages, since the > global mask is still there. BTW, we might get problems with MULTIPLE="yes" > packages. OK, I reread what you wrote above until I got (I think) a clear idea of what you're talking about. This is what I think you're saying -- with some details changed, but same end result: /usr/portage/profiles/package.mask is the global mask and works as it does now. /usr/portage/profiles/[profiledir]/packages lists only "foo/bar", not "foo/bar-1.0". In other words, it is used to specify which packages are part of the system *only*. But not their versions. Then, we have new "release package lists" (like current-packages) for each package version, maybe in /usr/portage/release, with names like "/usr/portage/release/1.0_rc5, etc. These files list a single version/rev of every package on the system. These are known-good sets of packages -- the combinations that are tested by us when we release a new version of Gentoo Linux. The user must select a particular "system version" to use, usually done when Gentoo Linux is installed. Correct? Here's how I think you want the system to work. /usr/portage/profiles/package.mask masks out global bad packages. next, /usr/portage/profiles/[profiledir]/packages specifies what packages should be installed, and the big /usr/portage/release/1.0_rc5 list (very similar to current-packages) is used to determine what version to use. These are the only packages that are allowed to be installed. If you want to be able to install newer packages, then just delete /usr/portage/profiles/[profiledir]/packages and then you can install any package, and the dep system will choose the most recent version of a package to satisfy dependencies. ================= OK, hopefully I understood you correctly -- now, for my comments on your idea. Frankly, I like my method better :/ Here's why. I don't think we should look at a Gentoo Linux as a "1.0_rc4 system" or a "1.0" system. Instead, we should look at it as a "Gentoo Linux" system, consisting of a bunch of inter-related packages and dependencies. All these emerge features we are adding are for the express purpose of keeping a system up-to-date. If you simply want to run a "1.0_rc4" system all your life, then the *only* emerge feature you need is the ability for emerge to merge new revs of already-installed package versions. Because the only upgrading you'll be doing is to fix security holes or other quirks; you'll never be upgrading to a new version of a particular package. In other words, this is not the target audience of these new emerge features. These new emerge dependency features are for those who want to be able to keep their system up-to-date as new ebuilds are released on CVS, without depending on us providing a "brand-new ?.0 release" of Gentoo Linux every few months. The goal is to make incremental upgrades easy and safe. I think my solution is more geared towards this purpose, because it doesn't rely on a static "release package list", but is designed to work in as flexible a manner as possible -- relying on the dependency system to ensure compatibility, as it should. This is the expert system approach -- creating a set of requirements and having Portage determine an adequate solution. If we are going to use "release package lists", then there's almost no use for our dependency system -- we don't need that kind of intelligence -- and I don't think we can say we're that much better than RedHat, who release version 6.1, then 7, etc., etc. I'm more interested in the seamless transition *from* 6.1 *to* 7 than the 6.1 and 7 releases themselves. To me, that's what "system maintenance" is all about, and that's what I want (and what I think many FreeBSD people want) from a Gentoo Linux system. Best Regards, -- Daniel Robbins President/CEO http://www.gentoo.org Gentoo Technologies, Inc.