[gentoo-dev] package.mask

[gentoo-dev] package.mask

[Daniel Robbins]

Developers,

I just updated the current version of Portage on CVS (portage-1.5_pre10).
This version of portage seems to be working well for Achim, and now has
an additional new feature.

The /usr/portage/profiles/package.mask file can now be used to *eliminate*
packages for consideration by the auto-build system.  It's really useful
if you are adding experimental and not-quite-working packages to portage.
Simply add a dependency line to /usr/portage/package.mask that matches the particular
ebuild you'd like to mark as "not ready for others".  Each dependency should
appear on its own line, and "# style" comments are allowed as long as the
line begins with a "#".  Here's an example package.mask file:

#sys-apps/bash-2.05 is experimental (not really, this is just an example)
=sys-apps/bash-2.05

#sys-apps/foo (all versions) should *not* be available to end-users
sys-apps/foo

Right now, "=sys-apps/bash-2.05" is in the package.mask file as a placeholder.
As soon as Achim gets the new version of Portage on his system and tests out
the package.mask feature, it'll be removed :)  If you merge the brand-new
version of portage-1.5_pre10, you'll find that for the time being, bash-2.05
will not be found by "emerge".

However, you can still install masked packages using ebuild.

All developers should now use package.mask as a way to ensure that end-users
don't accidentally auto-merge experimental ebuilds.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] package.mask

[Achim Gottinger]

Daniel Robbins wrote:
> 
> Developers,
> 
> I just updated the current version of Portage on CVS (portage-1.5_pre10).
> This version of portage seems to be working well for Achim, and now has
> an additional new feature.
> 
> The /usr/portage/profiles/package.mask file can now be used to *eliminate*
> packages for consideration by the auto-build system.  It's really useful
> if you are adding experimental and not-quite-working packages to portage.
> Simply add a dependency line to /usr/portage/package.mask that matches the particular
> ebuild you'd like to mark as "not ready for others".  Each dependency should
> appear on its own line, and "# style" comments are allowed as long as the
> line begins with a "#".  Here's an example package.mask file:
> 
> #sys-apps/bash-2.05 is experimental (not really, this is just an example)
> =sys-apps/bash-2.05
> 
> #sys-apps/foo (all versions) should *not* be available to end-users
> sys-apps/foo

Daniel, I have a question, why is it easier to add a new file
(package.mask) that excludes packages
instead of using the already existing packages file for masquerading
(oposite of package.mask)?

BTW: it seems that the new readline version (4.2, required for
bash-2.05) is not 100% compatible to
4.1. I tried to compile postgress yesterday and it only works with 4.1
but fails with 4.2.
So it is a good idea too keep bash-2.05 in package.mask.

achim~

> 
> Right now, "=sys-apps/bash-2.05" is in the package.mask file as a placeholder.
> As soon as Achim gets the new version of Portage on his system and tests out
> the package.mask feature, it'll be removed :)  If you merge the brand-new
> version of portage-1.5_pre10, you'll find that for the time being, bash-2.05
> will not be found by "emerge".
> 
> However, you can still install masked packages using ebuild.
> 
> All developers should now use package.mask as a way to ensure that end-users
> don't accidentally auto-merge experimental ebuilds.
> 
> Best Regards,
> 
> --
> Daniel Robbins                                  <drobbins@gentoo.org>
> 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

Re: [gentoo-dev] package.mask

[Daniel Robbins]

On Sat, Apr 14, 2001 at 04:54:36PM +0200, Achim Gottinger wrote:

> Daniel, I have a question, why is it easier to add a new file (package.mask)
> that excludes packages instead of using the already existing packages file
> for masquerading (oposite of package.mask)?

Good question... and here's a (hopefully) good answer.  Consider what will
happen when we have 20 different system-profiles on portage, and you add one
experimental package to CVS.  You could either add 20 lines to
/usr/portage/profiles/[x]/packages, or add a single exclusion line to
/usr/portage/profiles/package.mask.  Remember that package.mask is shared by
*every* profile, while the packages file is profile-specific.  package.mask is
specifically designed so that developers can exclude experimental ebuilds by
adding one line to one file -- ebuilds that are not stable shouldn't be used
under *any* profile.  Now, CVS committers only need to modify a single file to
"mask out" the broken ebuilds rather than carefully tweak every existing
profile.  This will allow for us to have certain people who are just "profile
maintainers" -- maintaining a specific directory in /usr/portage/profiles --
but don't actually need to be up-to-date on which ebuilds are broken and which
work this week or the next. That's the job of the ebuild maintainers, who keep
/usr/portage/profiles/package.mask up-to-date to protect the profile
maintainers and end-users.

Lots of _underlines_ and *stars* around key words in the next paragraph just to
make it easier to read....

The purpose of the packages file is to describe the _minimal_ ebuilds that
should be installed under a *specific* profile, while package.mask describes
the files that should _not_ be installed under *any* profile.  Note that if a
package is _not_ listed in packages, it *can* still be merged by the user.  So,
the packages file is _not_ supposed to prevent merging of not-listed packages,
but rather require merging of packages (technically, satisfaction of
dependencies) that *are* listed.  For example, if you have a "minimal" profile,
the packages file may only have 15 entries, but the user will still be able to
merge GNOME if they choose to do so.

The purpose of this design philosophy is to help ensure a working system without
putting unnecessary restraints on the user.  Apologies for not explaining this
earlier; I thought you understood the concept behind the packages file.  In any
case, I hope you like the design -- personally, I think it's a good approach.

While I still need to figure out how to resolve conflicts between package lines
and the DEPEND/RDEPEND strings, this does not change the fact that the packages
file was always intended (by me, at least) to list minimal-compliance
requirements (dependencies) for a specific profile, rather than an exhaustive
list of every possible package that is allowed to be installed like
current-packages.new did.  That's the concept behind a system profile -- to
identify a subset of the packages on CVS that constitute a complete system.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] package.mask

[Achim Gottinger]

> The purpose of this design philosophy is to help ensure a working system without
> putting unnecessary restraints on the user.  Apologies for not explaining this
> earlier; I thought you understood the concept behind the packages file.  In any
> case, I hope you like the design -- personally, I think it's a good approach.

Hmm, ok my idea whould mess up the idea of the packages file.

Here is an alternative to the package.mask concept. We can start tagging
packages in the cvs tree.
So by default you whould checkout the latest rc instead of the in
development versions. If you want to
add a development version to your system you can checkout manually.
Instead of using the gentoo version number for tagging we can use
"stable" for all packages not in development.
This should be sufficient for the beginning, but in the future I think
we need to use the version numbers.
The past shows that it is a nice idea to have an allways up to date
system, but some updates can create lots of
unexpectable bugs. To avoid messing up all our users system, we can
instead maintain our different releases 
separate and make only security fixes to them. So you can allways have a
secure rc4,rc5 1.0 1.1 ....

achim~

Re: [gentoo-dev] package.mask

[Daniel Robbins]

On Sat, Apr 14, 2001 at 07:14:56PM +0200, Achim Gottinger wrote:

> Here is an alternative to the package.mask concept. We can start tagging
> packages in the cvs tree.  So by default you whould checkout the latest rc
> instead of the in development versions. If you want to add a development
> version to your system you can checkout manually.  Instead of using the
> gentoo version number for tagging we can use "stable" for all packages not in
> development.  This should be sufficient for the beginning, but in the future
> I think we need to use the version numbers.  The past shows that it is a nice
> idea to have an allways up to date system, but some updates can create lots
> of unexpectable bugs. To avoid messing up all our users system, we can
> instead maintain our different releases separate and make only security fixes
> to them. So you can allways have a secure rc4,rc5 1.0 1.1 ....

I'm not a big fan of cvs, so I'd rather avoid using cvs to handle different
versions of Gentoo, except as a last resort.  In the future, I think we'll
probably have a stable and development branch of Gentoo Linux.  But I only want
to have a maximum of two (maybe three if we are working on a new stable
release) active, secure branches of Gentoo Linux at any time.  If possible, I
think we should look for ways to avoid dividing Gentoo Linux using cvs because
generally this ends up splitting the development team into two camps, or
doubling the work of the active developers such as yourself, because then we
are effectively supporting two separate versions of Gentoo Linux at the same
time.

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.  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.

But until we reach version 1.0, we shouldn't even be thinking about creating a
"stable" or "unstable" branch of Gentoo Linux.... everything on cvs is
"unstable" (technically) at this point.  Or, as the BSD people prefer calling
it -- "current".

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] package.mask

[Achim Gottinger]

Daniel Robbins wrote:
> 
> On Sat, Apr 14, 2001 at 07:14:56PM +0200, Achim Gottinger wrote:
> 
> > Here is an alternative to the package.mask concept. We can start tagging
> > packages in the cvs tree.  So by default you whould checkout the latest rc
> > instead of the in development versions. If you want to add a development
> > version to your system you can checkout manually.  Instead of using the
> > gentoo version number for tagging we can use "stable" for all packages not in
> > development.  This should be sufficient for the beginning, but in the future
> > I think we need to use the version numbers.  The past shows that it is a nice
> > idea to have an allways up to date system, but some updates can create lots
> > of unexpectable bugs. To avoid messing up all our users system, we can
> > instead maintain our different releases separate and make only security fixes
> > to them. So you can allways have a secure rc4,rc5 1.0 1.1 ....
> 
> I'm not a big fan of cvs, so I'd rather avoid using cvs to handle different
> versions of Gentoo, except as a last resort.  In the future, I think we'll
> probably have a stable and development branch of Gentoo Linux.  But I only want
> to have a maximum of two (maybe three if we are working on a new stable
> release) active, secure branches of Gentoo Linux at any time.  If possible, I
> think we should look for ways to avoid dividing Gentoo Linux using cvs because
> generally this ends up splitting the development team into two camps, or
> doubling the work of the active developers such as yourself, because then we
> are effectively supporting two separate versions of Gentoo Linux at the same
> time.
> 
> 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. :-)


 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. :-)

achim~

> 
> But until we reach version 1.0, we shouldn't even be thinking about creating a
> "stable" or "unstable" branch of Gentoo Linux.... everything on cvs is
> "unstable" (technically) at this point.  Or, as the BSD people prefer calling
> it -- "current".
> 
> --
> Daniel Robbins                                  <drobbins@gentoo.org>
> 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

Re: [gentoo-dev] package.mask

[Daniel Robbins]

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.

> >  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.

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.

Let's think about this proposed use of "packages" for a bit, and then I'll
implement it if everyone is OK with it.

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] package.mask

[Achim Gottinger]

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@gentoo.org>
> 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

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

Re: [gentoo-dev] package.mask

[Achim Gottinger]

Hi,

I think this concept is good for development, but it can cause problems
in productive environments.
It would be interesting to hear what our users think about, that's why
we discuss this on the list.

achim~

[gentoo-dev] package.mask

[Zach Forrest]

I was wanting to give the new sandbox a try, but I'm not sure how to get 
around package.mask. Does setting MAINTAINER=YES in make.conf have 
anything to do with this? What are the policies on getting CVS access?

Zach

Re: [gentoo-dev] package.mask

[Geert Bevin]

Just untar the archive and install with 'ebuild sandbox-0.2.1.ebuild 
merge'. This should work. To be completely protected also install the 
dynamic bash in a similar way 'ebuild dynbash-2.04.ebuild merge'. Note 
that there is a small risk to installing a dynamic bash : updating glibc 
afterwards crashes your machine, and updating ncurses and readline 
segfaults the running bashes. The static bash is however not removed but 
accessible as /bin/sbash. Unmerging the dynbash also puts the default 
static bash pack into its place, so you can always revert.

Zach Forrest wrote:

> I was wanting to give the new sandbox a try, but I'm not sure how to 
> get around package.mask. Does setting MAINTAINER=YES in make.conf have 
> anything to do with this? What are the policies on getting CVS access?
>
> Zach

Re: [gentoo-dev] package.mask

[Zach Forrest]

Thanks.

Geert Bevin wrote:

> Just untar the archive and install with 'ebuild sandbox-0.2.1.ebuild 
> merge'. This should work. To be completely protected also install the 
> dynamic bash in a similar way 'ebuild dynbash-2.04.ebuild merge'. Note 
> that there is a small risk to installing a dynamic bash : updating glibc 
> afterwards crashes your machine, and updating ncurses and readline 
> segfaults the running bashes. The static bash is however not removed but 
> accessible as /bin/sbash. Unmerging the dynbash also puts the default 
> static bash pack into its place, so you can always revert.
> 
> Zach Forrest wrote:
> 
>> I was wanting to give the new sandbox a try, but I'm not sure how to 
>> get around package.mask. Does setting MAINTAINER=YES in make.conf have 
>> anything to do with this? What are the policies on getting CVS access?
>>
>> Zach
> 
> 
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 

[gentoo-dev] package.mask

[Eric Thibeault Jolin]

Portage works like a charm, but it is a chore to use package.masked 
stuff and update often.
I want a /etc/package.mask file that doesn't get modified by portage and 
overrides /usr/portage/profile/package.mask. I also want the ability to 
write something like "! >=gnome-base/gnome-2.0.0_beta5" to force 
unmasking a package. But user masking will be nice too, like to force 
not installing jdk 1.4 on "emerge--update world" or to "remove nautilus 
from gnome-base", at least in effect. When I said portage shouldn't 
tamper with it, a possible exception might be when a package forced 
unmasked in /etc is permanently removed from 
/usr/portage/profile/package.mask, it might be good to remove it from 
/etc/package.mask (respecting config protection, of course).

On the other point of view, a /etc/package.protect file might be useful 
to manually protect a package or version of package from being removed 
by "emerge clean".

As I said, it already works wonders, but these small changes and it will 
be perfect! Okay, maybe not... almost perfect.

Re: [gentoo-dev] package.mask

[Tom Syroid]

YES! (thanks, Eric),

to chime in on this thread...

Most uses of Gentoo are mature, bleeding edge folk who -should- know the 
danger of blindly "emerging" -u world (if not, they need to relearn the 
*NIX tradition of RTFM).

But I too would like to see a way of "locking down" my "unmasks". For 
example, I've been compiling everything using BINUTILS-2.12 (?) for weeks 
now without problems or difficulties. It's a royal pain, however, to have 
to edit my ../profiles/default-1.0/packages after every emerge.

I'll state openly that I'm not a programmer, so I have no idea how 
difficult the aforementioned would be, but it sure would be *nice* to have 
some mask control built into Portage.

Best,
/tom

--On Friday, June 07, 2002 15:27:42 -0400 Eric Thibeault Jolin 
<irise-lenoir@sympatico.ca> wrote:

>
> Portage works like a charm, but it is a chore to use package.masked stuff
> and update often. I want a /etc/package.mask file that doesn't get
> modified by portage and overrides /usr/portage/profile/package.mask. I
> also want the ability to write something like "!
> >=gnome-base/gnome-2.0.0_beta5" to force unmasking a package. But user
> masking will be nice too, like to force not installing jdk 1.4 on
> "emerge--update world" or to "remove nautilus from gnome-base", at least
> in effect. When I said portage shouldn't tamper with it, a possible
> exception might be when a package forced unmasked in /etc is permanently
> removed from /usr/portage/profile/package.mask, it might be good to
> remove it from /etc/package.mask (respecting config protection, of
> course).
>
> On the other point of view, a /etc/package.protect file might be useful
> to manually protect a package or version of package from being removed by
> "emerge clean".
>
> As I said, it already works wonders, but these small changes and it will
> be perfect! Okay, maybe not... almost perfect.
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev