Gentoo Archives: gentoo-dev

From: Daniel Robbins <drobbins@g.o>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] package.mask
Date: Sat, 14 Apr 2001 15:27:41
In Reply to: Re: [gentoo-dev] package.mask by (Achim Gottinger)
1 On Sat, Apr 14, 2001 at 09:58:44PM +0200, Achim Gottinger wrote:
3 > > No, it isn't that complicated.
5 > Did I miss some mathematical break thrus? Let us just focus on glibc,
6 > ncurses and a package that requires both. Now assume we have 2 versions of
7 > glibc and 2 of ncurses. So we must get the package working with 4 different
8 > lib combinations. (no math study required for that example). We have a
9 > maximum dependencie dept at about 10 for some gnome package. Assume 2
10 > possibilities for for each dep and you must run 2^10 tests for a single
11 > package. Of cause it is not complicated to automate the tests, but it may
12 > take a while to run them.
14 OK, you are right -- we can't test every possible combination of packages with
15 one another. Maybe I should have said this: every .ebuild on CVS should work
16 on every Gentoo Linux system, as long as its DEPEND and RDEPEND variables can
17 be and are satisifed. If this is not the case, the package should be listed in
18 package.mask. So, if sys-apps/foo-1.0 requires sys-apps/bar-1.0, but there's
19 an entry in your current profile that reads:
21 !sys-apps/bar-1.0
23 Then, because of this entry, merging sys-apps/foo-1.0 will not be allowed on
24 your system. I guess what I'm trying to say is this -- the features I'm
25 talking about should allow us to create many "virtual systems", all from a
26 single unbranched cvs repository. All we need to do is to make sure that the
27 latest rev of working older ebuilds are kept for compatibility's sake, so that
28 there is more than just the latest version of a particular .ebuild available.
29 For example, keeping bash-2.04-r3.ebuild on CVS so that systems that aren't
30 allowed to run bash-2.05 still have a valid bash shell ebuild. This should
31 eliminate the need for branching our CVS tree.
33 > No I ment !sys-apps/bash-2.04 in package.mask.
35 Oh, ok. Right now, "!" deps are not allowed in package.mask, but I can make
36 them work. The problem is that in DEPEND, "!sys-apps/bash-2.04" means "not
37 sys-apps/bash-2.04", but in package.mask, it would have another meaning -- "any
38 version of sys-apps/bash *but* 2.04". So I would need to tweak the code a bit
39 to support this new use of the ! operator.
41 =, >=, >, <, <= and no operator are currently supported.
43 If needed, I can also get "foo? ( sys-apps/bar )"-type masks working. Right
44 now, I'm using the python dep_match() function, which is designed for =,>=,
45 etc, but not for ! or deps with multiple tokens (like "foo? ( bar )"). But I
46 can use a more advanced dep function if needed.
48 > > "ebuild" would still allow you to manually install a package if you absolutely
49 > > wanted to -- we will begin considering ebuild a low-level developer's tool as
50 > > emerge and pkgmerge become more feature-rich.
52 > Wouldn't it be easier to use emerge for pkgmerge too. emerge can check if a
53 > suitable tbz2-package exists for a required package and uses this instead of
54 > building it. If you call emerge [package].tbz2, this packages .ebuild file is
55 > used.
57 Yes, I have plans to combine pkgmerge and emerge soon. First, I want to get
58 package.mask and packages finalized.
60 > But that whould break your first idea of the packages file.
62 There's no harm in throwing away an idea that was already broken :)
64 > How about using a global mask file to eliminate in development packages and a
65 > profile depending to controll packages versions more efficient. In this
66 > scenarion the packages file does only contain lines like sys-apps/bash
67 > without any version information. Once we have a rc4 we can list all packages
68 > with their versions in packages/rc4/package.mask with for example
69 > =sys-apps/bash-2.05. If you want to keep all packages on your system up to
70 > date, you can simply delete the profile depending package.mask file and can
71 > still be sure you don't get unusable in development packages, since the
72 > global mask is still there. BTW, we might get problems with MULTIPLE="yes"
73 > packages.
75 OK, I reread what you wrote above until I got (I think) a clear idea of what
76 you're talking about. This is what I think you're saying -- with some details
77 changed, but same end result:
79 /usr/portage/profiles/package.mask is the global mask and works as it does now.
81 /usr/portage/profiles/[profiledir]/packages lists only "foo/bar", not
82 "foo/bar-1.0". In other words, it is used to specify which packages are part
83 of the system *only*. But not their versions.
85 Then, we have new "release package lists" (like current-packages) for each
86 package version, maybe in /usr/portage/release, with names like
87 "/usr/portage/release/1.0_rc5, etc. These files list a single version/rev of
88 every package on the system. These are known-good sets of packages -- the
89 combinations that are tested by us when we release a new version of Gentoo
90 Linux. The user must select a particular "system version" to use, usually done
91 when Gentoo Linux is installed. Correct?
93 Here's how I think you want the system to work.
95 /usr/portage/profiles/package.mask masks out global bad packages.
97 next, /usr/portage/profiles/[profiledir]/packages specifies what packages
98 should be installed, and the big /usr/portage/release/1.0_rc5 list (very
99 similar to current-packages) is used to determine what version to use. These
100 are the only packages that are allowed to be installed. If you want to be able
101 to install newer packages, then just delete
102 /usr/portage/profiles/[profiledir]/packages and then you can install any
103 package, and the dep system will choose the most recent version of a package to
104 satisfy dependencies.
106 =================
108 OK, hopefully I understood you correctly -- now, for my comments on your idea.
109 Frankly, I like my method better :/ Here's why. I don't think we should look
110 at a Gentoo Linux as a "1.0_rc4 system" or a "1.0" system. Instead, we should
111 look at it as a "Gentoo Linux" system, consisting of a bunch of inter-related
112 packages and dependencies. All these emerge features we are adding are for the
113 express purpose of keeping a system up-to-date.
115 If you simply want to run a "1.0_rc4" system all your life, then the *only*
116 emerge feature you need is the ability for emerge to merge new revs of
117 already-installed package versions. Because the only upgrading you'll be doing
118 is to fix security holes or other quirks; you'll never be upgrading to a new
119 version of a particular package. In other words, this is not the target
120 audience of these new emerge features.
122 These new emerge dependency features are for those who want to be able to keep
123 their system up-to-date as new ebuilds are released on CVS, without depending
124 on us providing a "brand-new ?.0 release" of Gentoo Linux every few months. The
125 goal is to make incremental upgrades easy and safe. I think my solution is
126 more geared towards this purpose, because it doesn't rely on a static "release
127 package list", but is designed to work in as flexible a manner as possible --
128 relying on the dependency system to ensure compatibility, as it should. This
129 is the expert system approach -- creating a set of requirements and having Portage
130 determine an adequate solution.
132 If we are going to use "release package lists", then there's almost no use for
133 our dependency system -- we don't need that kind of intelligence -- and I don't
134 think we can say we're that much better than RedHat, who release version 6.1,
135 then 7, etc., etc. I'm more interested in the seamless transition *from* 6.1
136 *to* 7 than the 6.1 and 7 releases themselves. To me, that's what "system
137 maintenance" is all about, and that's what I want (and what I think many FreeBSD
138 people want) from a Gentoo Linux system.
140 Best Regards,
142 --
143 Daniel Robbins <drobbins@g.o>
144 President/CEO
145 Gentoo Technologies, Inc.


Subject Author
Re: [gentoo-dev] package.mask (Achim Gottinger)