Re: [gentoo-dev] package.mask

[Daniel Robbins]

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					<drobbins@g.o>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.