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, DMARC_MISSING,FREEMAIL_FROM,INVALID_DATE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=no autolearn_force=no version=4.0.0 Received: from mailout04.sul.t-online.com ([194.25.134.18]) by cvs.gentoo.org with esmtp (Exim 3.22 #1) id 14oWdi-0008Rl-00 for gentoo-dev@gentoo.org; Sat, 14 Apr 2001 14:27:26 -0600 Received: from fwd07.aul.t-online.de by mailout04.sul.t-online.com with smtp id 14oWcu-0002VS-05; Sat, 14 Apr 2001 22:26:36 +0200 Received: from helios.bagwan (320095285153-0001@[62.155.143.248]) by fwd07.sul.t-online.com with smtp id 14oWcj-27QYGuC; Sat, 14 Apr 2001 22:26:25 +0200 Received: (qmail 12945 invoked by uid 0); 14 Apr 2001 23:09:55 -0000 Received: from sadchitananda2.bagwan (HELO gentoo.org) (achim@192.168.2.1) by helios.bagwan with SMTP; 14 Apr 2001 23:09:55 -0000 Message-ID: <3AD8ABF4.47F30206@gentoo.org> From: AGottinger@t-online.de (Achim Gottinger) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] package.mask 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 320095285153-0001@t-dialin.net 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 X-Reply-To: achim@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Sat Apr 14 14:28:01 2001 X-Original-Date: Sat, 14 Apr 2001 21:58:44 +0200 X-Archives-Salt: 85ad89dd-755a-485b-a9fb-6f819733ef61 X-Archives-Hash: c0f6bb886f1f8d0868f70e53d578e18f Daniel Robbins wrote: > > On Sat, Apr 14, 2001 at 08:10:58PM +0200, Achim Gottinger wrote: > > > > Soon, we'll have all the features in Portage to ensure that the *right* > > > versions of packages get installed (not just the most recent that satisifies > > > the dependency). If we then focus on ensuring that all the various ebuilds on > > > CVS will compile under any version of Gentoo Linux, then I don't think we have > > > a problem anymore. > > > > And this is less work that maintaining different branches? > > I think this is MI-3 Odysee-2100 to jupiter. :-) > > 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. > > > > We can have certain expectations as to ebuild compatibility > > > -- for example, we can make a rule that any Gentoo Linux 1.x ebuild should be > > > able to compile on any other Gentoo Linux 1.x system (whether "stable" or > > > "current"). If an ebuild doesn't meet this rule, then this particular version > > > should be blocked out of the appropriate packages files, i.e. > > > <=sys-apps/bash-2.05 would block out sys-apps/bash-2.06 or later. > > > does this work > > > > !sys-apps/bash-2.04 > > > > if I only want to use bash-2.04 and no other version? > > You know, never touch a running system. :-) > > If you don't want to change any of your packages, then what are you doing running > "emerge system" in the first place? :) > > If you just wanted sys-apps/bash-2.04 to be considered during an "emerge > system", then you should have this in your packages file: > > =sys-apps/bash-2.04 > > Right now, the packages file is only used during an "emerge system", but it > will be used more extensively in the very near future. I'd like it to be used > for *all* dependency checking. > > I'm thinking that each line in "packages" can specify two things at the same > time. First, it specifies a package or range of packages that *must* be > installed (or *must not* be installed) in order to make the system > profile-compliant. > > Secondly, each entry in "packages" also specifies a subrange of packages that will > be considered for resolving dependencies -- the opposite of package.mask. If you > want to specify a required package without a subrange, you would simply enter: > > sys-apps/bash > > But, if you have "=sys-apps/bash-2.04" in the packages file, then only this version > will be listed as available and used to resolve deps. > > If a package *isn't* listed in "packages", then: > 1. There is no requirement for this particular package to be installed, > 2. There is no requirement for this particular package to *not* be installed, > 3. There are no restrictions placed on what versions of this package are > considered when resolving auto-dependencies. > > If "!sys-apps/bash-2.04" were in the packages file, then every package *but* bash-2.04 > would be considered in resolving sys-apps/bash deps. No I ment !sys-apps/bash-2.04 in package.mask. > > This solution should give everyone lots of control over what gets installed and > create a clear dependency "command structure". My previous concept would allow > for DEPEND and RDEPEND to "clash" with the packages file. With the above > proposal, this is no longer possible -- the "packages" file has authority. > > emerge chain of command is as follows: > 1. package.mask eliminates unstable ebuilds > 2. packages specifies required packages and optionally eliminates certain > versions of packages from consideration. > 3. DEPEND and RDEPEND are evaluated as usual, except all ebuilds eliminated > during steps 1 and 2 are effectively ignored. > > "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. > > Let's think about this proposed use of "packages" for a bit, and then I'll > implement it if everyone is OK with it. But that whould break your first idea of the packages file. 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. achim~ > > -- > Daniel Robbins > President/CEO http://www.gentoo.org > Gentoo Technologies, Inc. > > _______________________________________________ > gentoo-dev mailing list > gentoo-dev@gentoo.org > http://www.gentoo.org/mailman/listinfo/gentoo-dev