On Thu, 25 Oct 2007 22:14:40 -0700
"Alec Warner" <[EMAIL PROTECTED]> wrote:
> > Another issue that isn't directly related, but covered by the
> > proposed solution below, is the so called "implicit system
> > dependency" in ebuilds, which doesn't really exist. It only an
> > assumption by people t
On 10/24/07, Marius Mauch <[EMAIL PROTECTED]> wrote:
> As package sets are mostly done now, I'm starting to think about
> something else. One of my pet peeves with portage is the "packages"
> file in profiles, for several reasons:
> 1) it has two completely independent purposes
ok
> 2) it impleme
Marius Mauch wrote:
On Wed, 24 Oct 2007 13:34:44 -0500
Andrew Gaffney <[EMAIL PROTECTED]> wrote:
For packages that are in the "system" set, wouldn't adding the
contents of system.{,r}depend to {,R}DEPEND cause problems in dep
resolution? Would there be a way to prevent the contents of these
fil
On Wed, 24 Oct 2007 13:34:44 -0500
Andrew Gaffney <[EMAIL PROTECTED]> wrote:
> For packages that are in the "system" set, wouldn't adding the
> contents of system.{,r}depend to {,R}DEPEND cause problems in dep
> resolution? Would there be a way to prevent the contents of these
> files from being a
Marius Mauch wrote:
As package sets are mostly done now, I'm starting to think about
something else. One of my pet peeves with portage is the "packages"
file in profiles, for several reasons:
1) it has two completely independent purposes
2) it implements a redundant visibility filter as package.m
As package sets are mostly done now, I'm starting to think about
something else. One of my pet peeves with portage is the "packages"
file in profiles, for several reasons:
1) it has two completely independent purposes
2) it implements a redundant visibility filter as package.mask is also
available
