Re: [gentoo-dev] package.mask

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