Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable

[Paul de Vrieze <pauldv@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]

On Thursday 26 January 2006 18:30, MIkey wrote:
> Alec Warner wrote:
> > Maybe you think fixing a circular dep is easy, I know I do.  But when
> > Joe Shmoe think it's OMG U63r 1337 to install gentoo using a stage1
> > because it makes his system so awesomely fast ( hence, The Conrad
> > install on the forums, heh ;) ) and he has no ****ing clue how any of
> > this crap works, and you tell him to fix the circular deps.  He isn't,
> > he is going to file a bug, which will be marked WONTFIX.  We know there
> > are circular deps, it's unavoidable in many situations.
>
> In no way am I suggesting to EVER support ANY installation method that goes
> beyond what is already supposed to be allowed in bootstrap.sh and
> conservative CFLAGS.
>
> Portage cannot easily enforce limits on what users choose, and it
> shouldn't, it is a package manager not a system maintenance tool.
>
> You can, however, test, duplicate, and guarantee results using methods such
> as bootstrap.sh, which can easily enforce limits and account for circular
> dependencies.  If you can do it from the command line, you can do it in a
> simple script.
>
> The bootstrap script _does_ work now, in spite of the openssl/python-fcksum
> circular dependencies a few months ago.  Portage needed fixing, not the
> entire installation method.
>
> > The problem with a stage1 as *I* see it, is it that it's a grab-bag
> > system.  A half-built system that some user, even following the official
> > docs, can fuck up in a myriad of ways, just by turning on use flags.
> > USE flags that that enable things that cause dep circles, enabling
> > things that cause other things to not compile because the stage1 ISN'T a
> > full system.  Our deptrees aren't complete, they make assumptions about
> > the current system, and those assumptions generally are not true on a
> > stage1 or stage2 system.
>
> If you can't get it up from a bootstrap position, you merely mask the real
> problems and put off dealing with them until later, in a much crazier
> environment.  If you can consistently obtain a working bootstrap
> environment for portage, no use flag _should_ matter afterwards.  The same
> use flag will break a stage3, stage4, or stage99090 install.  emerge -e
> system should work, every time, from a known baseline position.  If it does
> not, something is broke.

The problem is the complexity of system. You might be interested in knowning 
that with certain useflags system may pull in X as well as other complex 
ebuilds. Having said that, as long as the primary system packages are 
installed all ebuilds should build properly, including those in system. The 
problem is however that in stage 2 (after bootstrap.sh) not nearly all 
ebuilds are installed, but packages pulled in to system because of use flag 
dependencies might assume system is installed.

> I have a hunch that judicious use of the build/bootstrap flags might be
> able to get around most circular dependencies.  I don't know portage well
> enough to determine that.

The ebuilds are not done in that way, the problem is portage's inability to 
handle this. There is no way ebuilds could solve this problem except not 
having the dependency. What is needed to solve it is merge perl without ssl 
support, merge openssl, merge perl with ssl support. This is however not 
clear to portage, so it doesn't know how to solve this. Such dependencies are 
mainly present in system, so starting from a stage 3 solves all these 
problems.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]