[gentoo-dev] bootstrapping since gcc 3.4 is stable

[gentoo-dev] bootstrapping since gcc 3.4 is stable

[Sven Köhler]

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

Hi,

bootstrap.sh installs gcc 3.4! So far so good, but gcc 3.3 is not
unmerged. The consequence is, that "emerge -e system" installs gcc 3.4
and then afterwards gcc 3.3 instead of libstdc++-v3.

I'd like to see, that bootstrap.sh unmerges any old gcc
(emerge -C \<${gcc package that we just compiled})
so that a clean system is built with gcc 3.4 only!


Greetings
  Sven


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Wednesday 25 January 2006 07:30, Sven Köhler wrote:
> I'd like to see, that bootstrap.sh unmerges any old gcc
> (emerge -C \<${gcc package that we just compiled})

that's a bad idea imo

let the user decide which gcc they wish to have

> so that a clean system is built with gcc 3.4 only!

it wouldnt anyways as the version of gcc isnt changed unless the user does so

so unless you ran `gcc-config 3.4.4`, your gcc version would still be 3.3.x
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Sven Köhler]

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

>> I'd like to see, that bootstrap.sh unmerges any old gcc
>> (emerge -C \<${gcc package that we just compiled})
> 
> that's a bad idea imo
> 
> let the user decide which gcc they wish to have

But doesn't bootstrap.sh rebuild gcc? I have to take a look again, but i
think bootstrap.sh rebuilt gcc 3.4 only - not 3.3.
gcc 3.3 was only rebuilt during "emerge -e system".



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Marius Mauch]

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

On Wed, 25 Jan 2006 17:23:20 +0100
Sven Köhler <skoehler@upb.de> wrote:

> >> I'd like to see, that bootstrap.sh unmerges any old gcc
> >> (emerge -C \<${gcc package that we just compiled})
> > 
> > that's a bad idea imo
> > 
> > let the user decide which gcc they wish to have
> 
> But doesn't bootstrap.sh rebuild gcc? I have to take a look again,
> but i think bootstrap.sh rebuilt gcc 3.4 only - not 3.3.
> gcc 3.3 was only rebuilt during "emerge -e system".

that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system`
would have rebuilt it, not the 3.3 version (unless there is a dep on
<3.4 in system).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mikey]

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

On Wednesday 25 January 2006 10:38, Marius Mauch spammed:
> that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system`
> would have rebuilt it, not the 3.3 version (unless there is a dep on
> <3.4 in system).

Does this have something to do with it?

gcc-3.4.4-r1.ebuild:

PDEPEND="|| ( app-admin/eselect-compiler sys-devel/gcc-config )
	x86? ( !nocxx? ( !elibc_uclibc? ( !build? ( || ( sys-libs/libstdc++-v3 =sys-devel/gcc-3.3* ) ) ) ) )"

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

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

[Sven Köhler]

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

>> that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system`
>> would have rebuilt it, not the 3.3 version (unless there is a dep on
>> <3.4 in system).
> 
> Does this have something to do with it?
> 
> gcc-3.4.4-r1.ebuild:
> 
> PDEPEND="|| ( app-admin/eselect-compiler sys-devel/gcc-config )
> 	x86? ( !nocxx? ( !elibc_uclibc? ( !build? ( || ( sys-libs/libstdc++-v3 =sys-devel/gcc-3.3* ) ) ) ) )"

I think so. Because gcc 3.3 is installed, portage chooses gcc 3.3
instead of libstdc++-v3.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Wednesday 25 January 2006 11:38, Marius Mauch wrote:
> On Wed, 25 Jan 2006 17:23:20 +0100
> Sven Köhler <skoehler@upb.de> wrote:
> > >> I'd like to see, that bootstrap.sh unmerges any old gcc
> > >> (emerge -C \<${gcc package that we just compiled})
> > >
> > > that's a bad idea imo
> > >
> > > let the user decide which gcc they wish to have
> >
> > But doesn't bootstrap.sh rebuild gcc? I have to take a look again,
> > but i think bootstrap.sh rebuilt gcc 3.4 only - not 3.3.
> > gcc 3.3 was only rebuilt during "emerge -e system".
>
> that sounds rather unlikely, if gcc-3.4 was installed `emerge -e system`
> would have rebuilt it, not the 3.3 version (unless there is a dep on
> <3.4 in system).

the -e system step probably rebuilt both
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Sven Köhler]

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

>> I'd like to see, that bootstrap.sh unmerges any old gcc
>> (emerge -C \<${gcc package that we just compiled})
> 
> that's a bad idea imo
> let the user decide which gcc they wish to have

So i understand what you're trying to tell me, but bootstrap.sh makes
the choice already:
bootstrap.sh only rebuilds gcc 3.4
(i looked that up in my emerge.log)

gcc 3.3 is only rebuild (and thereby updated) by "emerge -e system".

>> so that a clean system is built with gcc 3.4 only!
> 
> it wouldnt anyways as the version of gcc isnt changed unless the user does so
> 
> so unless you ran `gcc-config 3.4.4`, your gcc version would still be 3.3.x

Right, and it will be the gcc 3.3 included in the stage1 tarball - even
if a new gcc 3.3 version is available. So if the user wants to use gcc
3.3, he has to manually update gcc (for example to have features not
included in the gcc from the stage1 tarball).
For example my stage1 inclueded gcc 3.3.5* - but 3.3.6 is already stable.

So no matter if the user wants gcc 3.3 or gcc 3.4, the user has to do
something manually to get a "proper" gentoo.

If i may suggest something, then i would recomm that the user is abled
to specify the gcc installed by bootstrap.sh like this:
	bootstrap.sh --gccspec "=sys-devel/gcc-3.3*"

The default should be the "newest" gcc.

In the above example, bootstrap.sh installs GCCV="sys-devel/gcc-3.3.6"
After that, bootstrap.sh could unmerge the gcc included in the stage1 by
	emerge -C "<$GCCV" ">$GCCV"


Greetings
  Sven


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Wednesday 25 January 2006 15:44, Sven Köhler wrote:
> >> I'd like to see, that bootstrap.sh unmerges any old gcc
> >> (emerge -C \<${gcc package that we just compiled})
> >
> > that's a bad idea imo
> > let the user decide which gcc they wish to have
>
> So i understand what you're trying to tell me, but bootstrap.sh makes
> the choice already:
> bootstrap.sh only rebuilds gcc 3.4
> (i looked that up in my emerge.log)

you're looking at bootstrap wrong ... it forces a few native packages to the 
newest version available

in this case, bootstrap emerges gcc and portage picks the best one ... 
gcc-3.4.4

> >> so that a clean system is built with gcc 3.4 only!
> >
> > it wouldnt anyways as the version of gcc isnt changed unless the user
> > does so
> >
> > so unless you ran `gcc-config 3.4.4`, your gcc version would still be
> > 3.3.x
>
> Right, and it will be the gcc 3.3 included in the stage1 tarball - even
> if a new gcc 3.3 version is available. So if the user wants to use gcc
> 3.3, he has to manually update gcc (for example to have features not
> included in the gcc from the stage1 tarball).

if a user wants gcc-3.3 but not gcc-3.4, then it's their responsibility to 
mask it accordingly via /etc/portage

> So no matter if the user wants gcc 3.3 or gcc 3.4, the user has to do
> something manually to get a "proper" gentoo.

i dont know what you mean by "proper"

at any rate, this will all "fix" itself when 2006.0 is released

> If i may suggest something, then i would recomm that the user is abled
> to specify the gcc installed by bootstrap.sh like this:
> 	bootstrap.sh --gccspec "=sys-devel/gcc-3.3*"

no, use /etc/portage
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Sven Köhler]

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

> at any rate, this will all "fix" itself when 2006.0 is released

OK, i give up.

IMHO, i would expect that "/usr/portage/scripts/bootstrap.sh; emerge -e
system" results in a system, that has a certain "integrity" with a
minimum of manual steps. (gentoo install being as easy as possible)

At the moment, "/usr/portage/scripts/bootstrap.sh; emerge -e system"
produces a system, that is IMHO unexpected for most users.

That's not a problem for me. So excuse me that i wanted
gentoo-installation to be more simple.


Greetings
  Sven


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Jan Kundrát]

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

Sven Köhler wrote:
> That's not a problem for me. So excuse me that i wanted
> gentoo-installation to be more simple.

Seems like a bit ranting to me. Why do you use unsupported installation
method if you want it simple?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[MIkey]

Jan Kundrát wrote:

> Seems like a bit ranting to me. Why do you use unsupported installation
> method if you want it simple?

I don't know about Sven, but the reasons I prefer the "unsupported"
installation method is all outlined here:

http://badpenguins.com/gentoo-build-test/

-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

MIkey wrote:
> I don't know about Sven, but the reasons I prefer the "unsupported"
> installation method is all outlined here:
> 
> http://badpenguins.com/gentoo-build-test/

You're beating the dead horse here. That site contains FUD, period.

"What is most interesting to me about this discussion is the fact than
no one has bothered to offer any facts to back up these assertions." --
author should read any of the wolf31o2's mails about this subject.

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[MIkey]

Jan Kundrát wrote:

> "What is most interesting to me about this discussion is the fact than
> no one has bothered to offer any facts to back up these assertions." --
> author should read any of the wolf31o2's mails about this subject.

I _have_ read his "mails" about it, had several exchanges with him on the
topic myself.  As a matter of fact if you read the "FUD" you might note
some of his quotes are the reasons I ran the tests in the first place. 
Frankly, I believe he is wrong, and I explained why.

The FUD is that stage3 is a better installation process than a (corrected)
stage1.  The facts are right there in what I posted.  Stage3's take twice
as long rebuilding the same number of packages and introduce a plethora of
roadblocks in the build process unless you stay on a very narrow path.  How
any "developer" can claim that this is a quicker, cleaner, or easier
process to support is beyond me.  Maybe in bizarro world.  

I will stick to the facts myself, thank you very much.  I invite you to
actually read the reports I generated and tell where my conclusions are
wrong.  If you can't do that, you are fudding yourself.

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 18:02 -0600, MIkey wrote:
> Jan Kundrát wrote:
> 
> > "What is most interesting to me about this discussion is the fact than
> > no one has bothered to offer any facts to back up these assertions." --
> > author should read any of the wolf31o2's mails about this subject.
> 
> I _have_ read his "mails" about it, had several exchanges with him on the
> topic myself.  As a matter of fact if you read the "FUD" you might note
> some of his quotes are the reasons I ran the tests in the first place. 
> Frankly, I believe he is wrong, and I explained why.

You didn't follow the Handbook.  Your comments about compiling GCC 3
times are completely unbased, since you ran not only an "emerge -e
system" (which is recommended) but then immediately, and needlessly,
followed it up with an "emerge -e world" which pretty much blew any
results that you had gained out of the water.

> The FUD is that stage3 is a better installation process than a (corrected)
> stage1.  The facts are right there in what I posted.  Stage3's take twice
> as long rebuilding the same number of packages and introduce a plethora of
> roadblocks in the build process unless you stay on a very narrow path.  How
> any "developer" can claim that this is a quicker, cleaner, or easier
> process to support is beyond me.  Maybe in bizarro world.

There are no "facts" in what you posted.  In fact, it looks as if your
designs were tailored to find a way in which you could get a stage3 to
be slower.  If you're willing, I will work on the scripts to produce
*accurate* results for stages 1 and 3.  Essentially, your data was
worthless since you didn't follow any prescribed way of using a stage3
tarball, nor did you anywhere cite where you came up with your
procedures.

> I will stick to the facts myself, thank you very much.  I invite you to
> actually read the reports I generated and tell where my conclusions are
> wrong.  If you can't do that, you are fudding yourself.

I just did.  You can stick with your "facts" all that you want, but
they're incorrect.

Here's a simple pseudo-formula to determine just how off you were:

(Yes, this is simplified slightly)

stage1 == tarball + toolchain (bootstrap) + system
stage3 == tarball + system + depclean

I'm sorry, but I cannot possibly believe that compiling the toolchain +
the system target takes less time than only compiling system and
summarily removing unused packages.  This, by the way, would have
avoided the issues that you were having with things like "ls" being
broken.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mikey]

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

On Wednesday 25 January 2006 18:27, Chris Gianelloni wrote:

> You didn't follow the Handbook.  Your comments about compiling GCC 3
> times are completely unbased, since you ran not only an "emerge -e
> system" (which is recommended) but then immediately, and needlessly,
> followed it up with an "emerge -e world" which pretty much blew any
> results that you had gained out of the water.

No, I didn't follow the handbook because I knew a gcc migration was 
involved.  http://www.gentoo.org/doc/en/gcc-upgrading.xml, Code Listing 
3.6, suggests to emerge -e system emerge -e world as the "safe" route.

The goal was to get the current gentoo toolchain from the current portage 
snapshot and latest available stage3 tarball, using the stage3 installation 
method.  If I had followed the handbook, I would have ended up with gcc 
3.3.6 and gcc 3.4.4 installed, but everything built with 3.3.6.  So to be 
completely accurate, if I had gone by the handbook and not the gcc 
migration guide, the build times for the stage3 method would have taken 4x 
longer than a stage1 instead of 2x.

My entire point was the the mind blowing waste of time required to obtain a 
current gentoo install using the stage3 installation method.  Unbased?  I 
think not.

> There are no "facts" in what you posted.  In fact, it looks as if your
> designs were tailored to find a way in which you could get a stage3 to
> be slower.  If you're willing, I will work on the scripts to produce
> *accurate* results for stages 1 and 3.  Essentially, your data was
> worthless since you didn't follow any prescribed way of using a stage3
> tarball, nor did you anywhere cite where you came up with your
> procedures.

I didn't tailor anything, I followed the exact same process anyone would 
need to follow to download a stage3, install the current portage snapshot, 
and get their system compiled with the default stable gcc (3.4.4).

> I just did.  You can stick with your "facts" all that you want, but
> they're incorrect.

> Here's a simple pseudo-formula to determine just how off you were:
>
> (Yes, this is simplified slightly)
>
> stage1 == tarball + toolchain (bootstrap) + system
> stage3 == tarball + system + depclean

Try it.  Take my script and make it closer to the reality you describe.  As 
long as the end result is the same - a system compiled against the current 
stable gcc, using the current snapshot.

Sure, at some point in the future the "current" official stages will contain 
the "current" toolchain, and building from a stage3 will be quicker, much 
quicker.  But gentoo is a moving target, it does not stay static.  The 
stage1 method produces consistent results and it does not really matter 
what USE flags you throw at it, it works without having to jump through 
undocumented hoops.  That is until someone throws in circular dependencies, 
which are fairly easy to work around.

> I'm sorry, but I cannot possibly believe that compiling the toolchain +
> the system target takes less time than only compiling system and
> summarily removing unused packages.  This, by the way, would have
> avoided the issues that you were having with things like "ls" being
> broken.

It takes less time because the first pass of the bootstrap is a bootstrap 
pass.  With a corrected bootstrap.sh, just using userlocales (something 
nearly impossible to do on the first pass with the currently broken 
bootstrap.sh) cuts the build time almost a forth.  The first gcc build does 
not build g++ either, further cutting out unneeded double building.  You 
also don't waste your time upgrading from gcc 3.3.5, to gcc 3.3.6, to 
3.4.4.  I didn't make that shit up.

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

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

[Stephen P. Becker]

> The FUD is that stage3 is a better installation process than a (corrected)
> stage1.  The facts are right there in what I posted.  Stage3's take twice
> as long rebuilding the same number of packages and introduce a plethora of
> roadblocks in the build process unless you stay on a very narrow path.

Ahh, so you were the idiot that ran those tests.  Congratulations...you 
needlessly did a --emptytree world after you had already done 
--emptrytree system in order to bloat your results.

> I will stick to the facts myself, thank you very much.  I invite you to
> actually read the reports I generated and tell where my conclusions are
> wrong.  If you can't do that, you are fudding yourself.

They're wrong, and you are spreading FUD.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Wednesday 25 January 2006 19:13, Stephen P. Becker wrote:

> Ahh, so you were the idiot that ran those tests.  Congratulations...you
> needlessly did a --emptytree world after you had already done
> --emptrytree system in order to bloat your results.

RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml

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

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

[Dan Meltzer]

On 1/25/06, Mikey <mikey@badpenguins.com> wrote:
> On Wednesday 25 January 2006 19:13, Stephen P. Becker wrote:
>
> > Ahh, so you were the idiot that ran those tests.  Congratulations...you
> > needlessly did a --emptytree world after you had already done
> > --emptrytree system in order to bloat your results.
>
> RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml

SO you uhh.. just proved you have very little idea about gentoo, whats next?
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

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

[Stephen P. Becker]

Mikey wrote:
> On Wednesday 25 January 2006 19:13, Stephen P. Becker wrote:
> 
>> Ahh, so you were the idiot that ran those tests.  Congratulations...you
>> needlessly did a --emptytree world after you had already done
>> --emptrytree system in order to bloat your results.
> 
> RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml

You aren't serious, are you?  Did *you* read the fucking manual *and* 
comprehend it?  Methinks not...upgrading from 3.3 to 3.4 in a 
pre-existing install != installing from a fresh stage.  First, running 
bootstrap.sh with the new gcc version unmasked would completely get rid 
of the "-e system" part of that howto, since that would force your 
toolchain to rebuild itself.  Second, the -e world is to ensure that 
your full install (which surely has plenty of c++ apps outside of 
system) is linked against the libstdc++ of the new gcc.

Remember, in a pristine stage3, system == world.  Therefore, your 
"comparison" is really telling folks to emerge -e system twice in a row. 
  Doing bootstrap.sh followed by 'emerge -e system' from a stage3 is the 
same thing as doing bootstrap.sh followed by 'emerge -e system' from a 
stage1...sorry to burst your bubble.  So again, idiocy and FUD.

-Steve

-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Wednesday 25 January 2006 19:49, Stephen P. Becker wrote:

> You aren't serious, are you?  Did *you* read the fucking manual *and*
> comprehend it?  Methinks not...upgrading from 3.3 to 3.4 in a

I didn't write the manual, so save your hubris for whoever did.  I just 
followed its instructions, I ate the dog food.

> pre-existing install != installing from a fresh stage.  First, running
> bootstrap.sh with the new gcc version unmasked would completely get rid
> of the "-e system" part of that howto, since that would force your
> toolchain to rebuild itself.  Second, the -e world is to ensure that
> your full install (which surely has plenty of c++ apps outside of
> system) is linked against the libstdc++ of the new gcc.

The test has nothing to do with installing from a pre-existing install.  The 
test was getting a current gentoo stage tarball with a current portage 
snapshot up to date, stage1 -vs- stage3.  Nothing was unmasked either.  
Were you are pulling that from is beyond me.

Running an emerge -e system does not magically switch you over to the new 
gcc, it would uselessly recompile the entire system with gcc 3.3.4 again.  
Hence the need to READ AND COMPREHEND the instructions in the gcc migration 
guide, which was plainly announced in GWN at the time.  If you don't 
believe me, go troll around the forums a little and try to help the poor 
saps who didn't realize they needed to follow that guide.  Even half of the 
ones who did read the guide completely dorked up their running boxes.

> Remember, in a pristine stage3, system == world.  Therefore, your
> "comparison" is really telling folks to emerge -e system twice in a row.
>   Doing bootstrap.sh followed by 'emerge -e system' from a stage3 is the
> same thing as doing bootstrap.sh followed by 'emerge -e system' from a
> stage1...sorry to burst your bubble.  So again, idiocy and FUD.

If you actually downloaded a "pristine" stage1 or a stage3 tarball you might 
notice that there are, in fact, packages already present in world.  Glibc, 
gettext, nano, gzip, and linux-headers.  Not that that matters one iota to 
this conversation, but you need to get your own facts straight before 
running around calling people idiots.

The difference in doing from stage1 instead of stage3 is you don't have to 
go through a gcc migration to prevent your build from being unusable.  You 
also go through 1 gcc upgrade (gcc 3.3.5 -> gcc 3.4.4), not 3 (3.3.5 -> 
3.3.6 -> 3.4.4).  We are talking reality here, not fantasy.

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

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

[Donnie Berkholz]

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

Mikey wrote:
> If you actually downloaded a "pristine" stage1 or a stage3 tarball you might 
> notice that there are, in fact, packages already present in world.  Glibc, 
> gettext, nano, gzip, and linux-headers.  Not that that matters one iota to 
> this conversation, but you need to get your own facts straight before 
> running around calling people idiots.

Name one of those that isn't in 'system'.

donnie@supernova ~ $ emvp -e system | grep -e gzip -e linux-headers -e
nano -e gettext -e glibc
[ebuild  N    ] sys-kernel/linux-headers-2.6.11-r3  0 kB
[ebuild  N    ] app-arch/gzip-1.3.5-r8  USE="-build -nls -pic* -static" 0 kB
[ebuild  N    ] sys-devel/gettext-0.14.5  USE="emacs -doc -nls -nocxx%" 0 kB
[ebuild  N    ] sys-libs/glibc-2.3.6-r2  USE="glibc-omitfp nptl nptlonly
userlocales -build -erandom -glibc-compat20 -hardened -linuxthreads-tls
-nls -pic* -profile" 0 kB
[ebuild  N    ] app-editors/nano-1.3.10  USE="ncurses spell unicode
-build -debug -justify -minimal -nls -slang" 0 kB


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mikey]

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

On Wednesday 25 January 2006 20:53, Donnie Berkholz wrote:

> Name one of those that isn't in 'system'.
>
> donnie@supernova ~ $ emvp -e system | grep -e gzip -e linux-headers -e
> nano -e gettext -e glibc
> [ebuild  N    ] sys-kernel/linux-headers-2.6.11-r3  0 kB

Your point?  My point was that they don't belong there.

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

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

[Marcelo Góes]

On 1/26/06, Mikey <mikey@badpenguins.com> wrote:

> Your point?  My point was that they don't belong there.

Are you saying glibc should not be in system?
Do you know what system is for?

--
Marcelo Góes
marcelogoes@gmail.com
vanquirius@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Wednesday 25 January 2006 22:07, Mikey wrote:
> On Wednesday 25 January 2006 20:53, Donnie Berkholz wrote:
> > Name one of those that isn't in 'system'.
> >
> > donnie@supernova ~ $ emvp -e system | grep -e gzip -e linux-headers -e
> > nano -e gettext -e glibc
> > [ebuild  N    ] sys-kernel/linux-headers-2.6.11-r3  0 kB
>
> Your point?  My point was that they don't belong there.

actually, they should
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Thursday 26 January 2006 08:16, Mike Frysinger spammed:
> On Wednesday 25 January 2006 22:07, Mikey wrote:
> > On Wednesday 25 January 2006 20:53, Donnie Berkholz wrote:
> > > Name one of those that isn't in 'system'.
> > >
> > > donnie@supernova ~ $ emvp -e system | grep -e gzip -e linux-headers
> > > -e nano -e gettext -e glibc
> > > [ebuild  N    ] sys-kernel/linux-headers-2.6.11-r3  0 kB
> >
> > Your point?  My point was that they don't belong there.
>
> actually, they should

Why should system packages (determined by your profile) be present in the 
official stage1/3 tarballs?

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

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

[Mike Frysinger]

On Thursday 26 January 2006 10:42, Mikey wrote:
> On Thursday 26 January 2006 08:16, Mike Frysinger spammed:
> > On Wednesday 25 January 2006 22:07, Mikey wrote:
> > > On Wednesday 25 January 2006 20:53, Donnie Berkholz wrote:
> > > > Name one of those that isn't in 'system'.
> > > >
> > > > donnie@supernova ~ $ emvp -e system | grep -e gzip -e linux-headers
> > > > -e nano -e gettext -e glibc
> > > > [ebuild  N    ] sys-kernel/linux-headers-2.6.11-r3  0 kB
> > >
> > > Your point?  My point was that they don't belong there.
> >
> > actually, they should
>
> Why should system packages (determined by your profile) be present in the
> official stage1/3 tarballs?

do you even realize what you're asking ?
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

Mike Frysinger wrote:

>>
>> Why should system packages (determined by your profile) be present in the
>> official stage1/3 tarballs?
> 
> do you even realize what you're asking ?
> -mike

Duh, let me clarify that:

Why should system packages (determined by your profile) be present in the
world file on official stage1/3 tarballs?

-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Thursday 26 January 2006 11:06, MIkey wrote:
> Why should system packages (determined by your profile) be present in the
> world file on official stage1/3 tarballs?

whether they are in the world file itself doesnt really matter

the "world" target includes all the packages listed in the world file plus 
everything that is part of the "system" target ... portage adds them together 
automatically
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

Mike Frysinger wrote:

> On Thursday 26 January 2006 11:06, MIkey wrote:
>> Why should system packages (determined by your profile) be present in the
>> world file on official stage1/3 tarballs?
> 
> whether they are in the world file itself doesnt really matter
> 
> the "world" target includes all the packages listed in the world file plus
> everything that is part of the "system" target ... portage adds them
> together automatically
> -mike

/var/lib/portage/world should only contain the names of packages you
explicitly emerge (without --oneshot).  As far as I know an official stage3
tarball should only contain packages installed as a result of a system
emerge, which should never enter them into the world file.

-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Thursday 26 January 2006 14:00, MIkey wrote:
> Mike Frysinger wrote:
> > On Thursday 26 January 2006 11:06, MIkey wrote:
> >> Why should system packages (determined by your profile) be present in
> >> the world file on official stage1/3 tarballs?
> >
> > whether they are in the world file itself doesnt really matter
> >
> > the "world" target includes all the packages listed in the world file
> > plus everything that is part of the "system" target ... portage adds them
> > together automatically
>
> /var/lib/portage/world should only contain the names of packages you
> explicitly emerge (without --oneshot).  As far as I know an official stage3
> tarball should only contain packages installed as a result of a system
> emerge, which should never enter them into the world file.

they're probably recorded since tools like bootstrap.sh do not utilize 
--oneshot

either way, the whole issue is moot as i already pointed out, as portage will 
add all 'system' packages to the 'world' target automatically (and i dont 
mean they are recorded in the world file)
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Thursday 26 January 2006 14:08, Mike Frysinger wrote:
> On Thursday 26 January 2006 14:00, MIkey wrote:
> > /var/lib/portage/world should only contain the names of packages you
> > explicitly emerge (without --oneshot).  As far as I know an official
> > stage3 tarball should only contain packages installed as a result of a
> > system emerge, which should never enter them into the world file.
>
> they're probably recorded since tools like bootstrap.sh do not utilize
> --oneshot

we've tweaked bootstrap.sh to use --oneshot now
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Marcelo Góes]

On 1/26/06, Mikey <mikey@badpenguins.com> wrote:
> If you actually downloaded a "pristine" stage1 or a stage3 tarball you might
> notice that there are, in fact, packages already present in world.  Glibc,
> gettext, nano, gzip, and linux-headers.

Like it was already said, those are parts of system.
Have we any need of extending this flamewar?

--
Marcelo Góes
marcelogoes@gmail.com
vanquirius@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

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

[Stephen P. Becker]

Mikey wrote:
> On Wednesday 25 January 2006 19:49, Stephen P. Becker wrote:
> 
>> You aren't serious, are you?  Did *you* read the fucking manual *and*
>> comprehend it?  Methinks not...upgrading from 3.3 to 3.4 in a
> 
> I didn't write the manual, so save your hubris for whoever did.  I just 
> followed its instructions, I ate the dog food.

Which is precisely your problem.  You are blindly eating your food 
without contemplating the contents.


>> pre-existing install != installing from a fresh stage.  First, running
>> bootstrap.sh with the new gcc version unmasked would completely get rid
>> of the "-e system" part of that howto, since that would force your
>> toolchain to rebuild itself.  Second, the -e world is to ensure that
>> your full install (which surely has plenty of c++ apps outside of
>> system) is linked against the libstdc++ of the new gcc.
> 
> The test has nothing to do with installing from a pre-existing install.

Exactly!  Yet, the gcc upgrading guide which you follow so blindly and 
religiously *is* meant for upgrading from a pre-existing install.


> The test was getting a current gentoo stage tarball with a current portage 
> snapshot up to date, stage1 -vs- stage3.  Nothing was unmasked either.  
> Were you are pulling that from is beyond me.

I was just noting that in the past, gcc 3.4 would have been masked for 
some people.  If you want s/3.3/3.4/, and s/3.4/4.0/ now, because it is 
the same situation.  However, it really doesn't matter here.


> Running an emerge -e system does not magically switch you over to the new 
> gcc, it would uselessly recompile the entire system with gcc 3.3.4 again.

This is extremely funny.  So, without even comprehending what you are 
typing, you just said (in a roundabout way) that if you did bootstrap.sh 
and then used gcc-config to set 3.4 as your system compiler, that your 
system compiler would *not* be switched over to 3.3 at any time during 
emerge -e system...and you are 100% correct!  Remember, gcc is slotted. 
  If you are really that paranoid, simply unmerge the 3.3.x gcc after 
you have run bootstrap.sh.


> Hence the need to READ AND COMPREHEND the instructions in the gcc migration 
> guide, which was plainly announced in GWN at the time.  If you don't 
> believe me, go troll around the forums a little and try to help the poor 
> saps who didn't realize they needed to follow that guide.  Even half of the 
> ones who did read the guide completely dorked up their running boxes.

Wow, you sure like to contradict yourself.  You keep jumping back and 
forth between talking about a new install and running installs.  Care to 
make your mind up at some point?


>> Remember, in a pristine stage3, system == world.  Therefore, your
>> "comparison" is really telling folks to emerge -e system twice in a row.
>>   Doing bootstrap.sh followed by 'emerge -e system' from a stage3 is the
>> same thing as doing bootstrap.sh followed by 'emerge -e system' from a
>> stage1...sorry to burst your bubble.  So again, idiocy and FUD.
> 
> If you actually downloaded a "pristine" stage1 or a stage3 tarball you might 
> notice that there are, in fact, packages already present in world.  Glibc, 
> gettext, nano, gzip, and linux-headers.

Of course there are, but they are also part of system.  Remember, a 
stage3 is equivalent to having run bootstrap.sh followed by emerge 
system from a stage1.  This is how it has *always* been.


>  Not that that matters one iota to 
> this conversation, but you need to get your own facts straight before 
> running around calling people idiots.

My facts are already straight, and you are still an idiot.


> The difference in doing from stage1 instead of stage3 is you don't have to 
> go through a gcc migration to prevent your build from being unusable.  You 
> also go through 1 gcc upgrade (gcc 3.3.5 -> gcc 3.4.4), not 3 (3.3.5 -> 
> 3.3.6 -> 3.4.4).  We are talking reality here, not fantasy.

Your reality is fantasy.


-Steve

-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

Stephen P. Becker wrote:

> Which is precisely your problem.  You are blindly eating your food
> without contemplating the contents.

Perhaps I am just contemplating a little deeper than you are.
 
> 
>>> pre-existing install != installing from a fresh stage.  First, running
>>> bootstrap.sh with the new gcc version unmasked would completely get rid
>>> of the "-e system" part of that howto, since that would force your
>>> toolchain to rebuild itself.  Second, the -e world is to ensure that
>>> your full install (which surely has plenty of c++ apps outside of
>>> system) is linked against the libstdc++ of the new gcc.
>> 
>> The test has nothing to do with installing from a pre-existing install.
> 
> Exactly!  Yet, the gcc upgrading guide which you follow so blindly and
> religiously *is* meant for upgrading from a pre-existing install.

Which happens to be the exact same method to get a stage3 upgraded also. 
Feel free to provide me with a link to better official documentation that
covers it.

> I was just noting that in the past, gcc 3.4 would have been masked for
> some people.  If you want s/3.3/3.4/, and s/3.4/4.0/ now, because it is
> the same situation.  However, it really doesn't matter here.

I'm not talking about the past.  I can't travel through time and determine
what was and was not masked on your box.  The test condition was to get the
current stage3 installed with the current stable gcc, gcc-3.4.4 for x86.
 
> This is extremely funny.  So, without even comprehending what you are
> typing, you just said (in a roundabout way) that if you did bootstrap.sh
> and then used gcc-config to set 3.4 as your system compiler, that your
> system compiler would *not* be switched over to 3.3 at any time during
> emerge -e system...and you are 100% correct!  Remember, gcc is slotted.
>   If you are really that paranoid, simply unmerge the 3.3.x gcc after
> you have run bootstrap.sh.

In which case you would not be running a box with the current toolchain and
you would have to turn around and do it all over again later, therefore
wasting 4x the amount of time to get your stage3 and/or running install
upgraded.  To further educate you, there was a bug shortly after the
release of 3.4.4 into stable that did, in fact, automatically switch you
over to the new gcc.  It was in the toolchain eclass.
 
> Wow, you sure like to contradict yourself.  You keep jumping back and
> forth between talking about a new install and running installs.  Care to
> make your mind up at some point?

The test, what I am debating about, and my primary assertion is that the
stage3 installation method is not superior to the stage1/bootstrapping
installation method.  The official gcc migration instructions happen to be
the same for both a stage3 install and a running installation.  If you
cannot grasp nuanced discussion, I can't help you learn anything new.
 
> Of course there are, but they are also part of system.  Remember, a
> stage3 is equivalent to having run bootstrap.sh followed by emerge
> system from a stage1.  This is how it has *always* been.

No, they are not anywhere near the same.  The end goal is the same, how
effectively they get there and the predictability of reaching the desired
goal is very different.  If you find it a superior approach to go through
226 emerges instead of 99 over twice the amount of time to arrive at the
same destination, more power to you and the misinformed people who listen
to you.
 
> My facts are already straight, and you are still an idiot.

Whatever.

-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

MIkey wrote:
> To further educate you, there was a bug shortly after the
> release of 3.4.4 into stable that did, in fact, automatically switch you
> over to the new gcc.  It was in the toolchain eclass.

Great, there was a bug. Yeah, there was. Please notice the word "was".
It means that it has been fixed and it isn't there anymore. So the
problem got fixed. It's over. Finito. Period. Why are you still talking
about it?

> The official gcc migration instructions happen to be
> the same for both a stage3 install and a running installation.

Do you have some problems with understanding an English text? It was
already stated several times that upgrading GCC from fresh stage3 is
*not* the same as in the live system.

HTH,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[MIkey]

Jan Kundrát wrote:

> Great, there was a bug. Yeah, there was. Please notice the word "was".
> It means that it has been fixed and it isn't there anymore. So the
> problem got fixed. It's over. Finito. Period. Why are you still talking
> about it?

Because Becker needed to be informed about it.  I know it was fixed, I am
not bitching about it.  I am merely pointing out that a stage3 installation
isn't quite so simple to support and is just as prone (more prone in my
opinion) to problems as a stage1 installation method.  The main crux of
what I am saying is that it is, in fact, more error prone and takes longer.
 
>> The official gcc migration instructions happen to be
>> the same for both a stage3 install and a running installation.
> 
> Do you have some problems with understanding an English text? It was
> already stated several times that upgrading GCC from fresh stage3 is
> *not* the same as in the live system.

Where are they then?  How are they different?  You might want to let someone
else know.

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 23:07, MIkey wrote:
> Jan Kundrát wrote:
> > Great, there was a bug. Yeah, there was. Please notice the word "was".
> > It means that it has been fixed and it isn't there anymore. So the
> > problem got fixed. It's over. Finito. Period. Why are you still talking
> > about it?
>
> Because Becker needed to be informed about it.  I know it was fixed, I am
> not bitching about it.  I am merely pointing out that a stage3 installation
> isn't quite so simple to support and is just as prone (more prone in my
> opinion) to problems as a stage1 installation method.  The main crux of
> what I am saying is that it is, in fact, more error prone and takes longer.

Is it? There is no reason to perform a gcc update. While there are arguments 
for doing so, it is not needed. As such an unsuspecting user is less likely 
to break his system. Incorrect manual reading/following is however a big 
problem with stage 1 installs. They work, but they require you to either 
follow the instructions to the letter, or to really know what you're doing. 
With stage1 it's even more so that if it breaks, you get to keep the pieces.

> > Do you have some problems with understanding an English text? It was
> > already stated several times that upgrading GCC from fresh stage3 is
> > *not* the same as in the live system.
>
> Where are they then?  How are they different?  You might want to let
> someone else know.

This is only a temporary issue. As upgrading a stage3 is just a special case 
of upgrading a fully live system the instructions still apply. Having 
separate instructions is probably more confusing and a waste of developer 
effort.

Paul

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

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

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 20:23 -0600, Mikey wrote:
> If you actually downloaded a "pristine" stage1 or a stage3 tarball you might 
> notice that there are, in fact, packages already present in world.  Glibc, 
> gettext, nano, gzip, and linux-headers.  Not that that matters one iota to 
> this conversation, but you need to get your own facts straight before 
> running around calling people idiots.

Damn.  I have to bite.

All of these are in system, so please, give up until you have a clue
what you're talking about.

> The difference in doing from stage1 instead of stage3 is you don't have to 
> go through a gcc migration to prevent your build from being unusable.  You 
> also go through 1 gcc upgrade (gcc 3.3.5 -> gcc 3.4.4), not 3 (3.3.5 -> 
> 3.3.6 -> 3.4.4).  We are talking reality here, not fantasy.

You don't have to go through the whole migration to work from a stage3,
either.  Just because *you* did doesn't mean it is required, in any way.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mikey]

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

On Thursday 26 January 2006 08:06, Chris Gianelloni spammed:
> On Wed, 2006-01-25 at 20:23 -0600, Mikey wrote:
> > If you actually downloaded a "pristine" stage1 or a stage3 tarball you
> > might notice that there are, in fact, packages already present in
> > world.  Glibc, gettext, nano, gzip, and linux-headers.  Not that that
> > matters one iota to this conversation, but you need to get your own
> > facts straight before running around calling people idiots.
>
> Damn.  I have to bite.
>
> All of these are in system, so please, give up until you have a clue
> what you're talking about.

They are also already present in /var/lib/portage/world in the official 
release stage1/stage3 tarballs.  At least for x86.

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

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

[Dan Meltzer]

What eactly is your point? Of course they are.

On 1/26/06, Mikey <mikey@badpenguins.com> wrote:
> On Thursday 26 January 2006 08:06, Chris Gianelloni spammed:
> > On Wed, 2006-01-25 at 20:23 -0600, Mikey wrote:
> > > If you actually downloaded a "pristine" stage1 or a stage3 tarball you
> > > might notice that there are, in fact, packages already present in
> > > world.  Glibc, gettext, nano, gzip, and linux-headers.  Not that that
> > > matters one iota to this conversation, but you need to get your own
> > > facts straight before running around calling people idiots.
> >
> > Damn.  I have to bite.
> >
> > All of these are in system, so please, give up until you have a clue
> > what you're talking about.
>
> They are also already present in /var/lib/portage/world in the official
> release stage1/stage3 tarballs.  At least for x86.
>
>

-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Thursday 26 January 2006 08:06, Chris Gianelloni spammed:

> > The difference in doing from stage1 instead of stage3 is you don't have
> > to go through a gcc migration to prevent your build from being
> > unusable.  You also go through 1 gcc upgrade (gcc 3.3.5 -> gcc 3.4.4),
> > not 3 (3.3.5 -> 3.3.6 -> 3.4.4).  We are talking reality here, not
> > fantasy.
>
> You don't have to go through the whole migration to work from a stage3,
> either.  Just because *you* did doesn't mean it is required, in any way.

No you don't.  Except for the first time I ran an update immediately after 
it came out and I was, in fact, switched over to the new gcc, in spite of 
what the documentation said.  All I did was an emerge -u system.  I noticed 
it happened to several other users in the forums as well.

So as long as you are not inadvertently switched over to the new gcc or know 
not to switch over to it without going to the migration guide, everything 
should be peachy.

Will gcc-3.4.4 be required in the 2006.0 profile?

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

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 19:32 -0600, Mikey wrote:
> On Wednesday 25 January 2006 19:13, Stephen P. Becker wrote:
> 
> > Ahh, so you were the idiot that ran those tests.  Congratulations...you
> > needlessly did a --emptytree world after you had already done
> > --emptrytree system in order to bloat your results.
> 
> RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml

Except that is for an *already installed* system.

Again, you didn't take into account the simple thing called common
sense.  If you're already going to be doing an "emerge -e system" in
there, would it not make sense to:

emerge -uav gcc
gcc-config i686-pc-linux-gnu-3.4.4
source /etc/profile
emerge --oneshot -av libtool
emerge -eav system

Remember that with a stage3 tarball, you don't *have* a world to
rebuild, so you're simply rebuilding "system" twice.

As I said, you're wasting your time (and ours since we're continuing to
even talk to you on this).

At any rate, I'm not going to bother any more with this thread until I
rewrite the scripts to not make bad assumptions.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mikey]

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

On Thursday 26 January 2006 08:02, Chris Gianelloni spammed:
> >
> > RTFM - http://www.gentoo.org/doc/en/gcc-upgrading.xml
>
> Except that is for an *already installed* system.
>
> Again, you didn't take into account the simple thing called common
> sense.  If you're already going to be doing an "emerge -e system" in
> there, would it not make sense to:
>
> emerge -uav gcc
> gcc-config i686-pc-linux-gnu-3.4.4
> source /etc/profile
> emerge --oneshot -av libtool
> emerge -eav system

You guys have made the decision to stop supporting stage1 installs.  The 
"official" installation method is a stage3.  What I documented, and tested, 
is what you are telling users they have to do.  Download stage3, emerge 
--sync, update system.

The only problem is that you don't actually tell the users what to do when 
there are major issues, such as gcc upgrades.  There is no link in the 
handbook or the gentoo documentation page mentioning the fact that they 
can't just upgrade their gcc without going through the proper process you 
mention above.  What I documented is what any user would _need_ to do to 
get their system installed using your recommended installation method.

And those instructions have nothing whatsoever to do with common sense from 
a new, or even experienced users perspective.  Knowing that a gcc upgrade 
will break libtool is not common sense, nor is it commonly known.

> Remember that with a stage3 tarball, you don't *have* a world to
> rebuild, so you're simply rebuilding "system" twice.

Yes, but I have been called an idiot here for following the instructions 
given to upgrade gcc.  They are not my instructions, they are not the way I 
would do it, they are YOUR instructions.

> As I said, you're wasting your time (and ours since we're continuing to
> even talk to you on this).

You are certainly entitled to that opinion.

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

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

[Wernfried Haas]

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

On Thu, Jan 26, 2006 at 09:34:51AM -0600, Mikey wrote:
> The only problem is that you don't actually tell the users what to do when 
> there are major issues, such as gcc upgrades.  There is no link in the 
> handbook or the gentoo documentation page mentioning the fact that they 
> can't just upgrade their gcc without going through the proper process you 
> mention above.  What I documented is what any user would _need_ to do to 
> get their system installed using your recommended installation method.

You already complained about that on the forums [1] in a rather
similar thread and yet you still haven't filed a bug report about
it. I don't have the feeling this is going anywhere. I'd really
appreciate if you would at least try to help improve things.

[1] http://forums.gentoo.org/viewtopic-p-3043626.html#3043626

Btw, the update was announced all over the place, including GWN,
www.gentoo.org, the forums, etc. You also get a message in the
postinstall of gcc 3.4.4 iirc.

As for the stage 1 problems you described, this is exactly what i
already told you in the same thread. Supporting stage 1 costs extra
resources, this thread is a perfect example of it.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[Dale]

Wernfried Haas wrote:

>
>
>As for the stage 1 problems you described, this is exactly what i
>already told you in the same thread. Supporting stage 1 costs extra
>resources, this thread is a perfect example of it.
>
>cheers,
>	Wernfried
>
>  
>


I thought that if you chose to do a stage 1 install you were on your
own.  That was my understanding.  If that is true, he is getting support
for something that is not supported, right?

I'm shutting my non-dev mouth now.  I got to go see my lady.  ;-)

Dale
:-)

-- 
To err is human, I'm most certainly human.

I have four rigs:

1:  Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 80GB hard drives.  Named Smoker
2:  Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive.  Named Swifty
3:  Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 224MBs of ram and a 2.5GB drive.  Named Pokey
4:  Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB SCSI drive.  Named Putput

All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers.  

-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

Dale wrote:

> I thought that if you chose to do a stage 1 install you were on your
> own.  That was my understanding.  If that is true, he is getting support
> for something that is not supported, right?

I'm not asking for support, I'm giving it.

-- 
gentoo-dev@gentoo.org mailing list

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

[Pete Ezzo]

On 1/26/06, MIkey <mikey@badpenguins.com> wrote:
> Dale wrote:
> I'm not asking for support, I'm giving it.

are you still freaking writing?  you have proven yourself ignorant in
at least a dozen emails so far.  you don't understand portage.  you
don't understand system.  you don't understand how to read.  and you
certainly won't go away.

my official user opinion is that you should unsubscribe from this list
and go outside.  i'm a user, my opinion counts as much as yours right?

-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

Wernfried Haas wrote:

> You already complained about that on the forums [1] in a rather
> similar thread and yet you still haven't filed a bug report about

Why I explained a couple of posts further down.  I could not duplicate the
problem either, I think it went away in 3.4.4-r1.  I don't like posting bug
reports that I can't duplicate and I prefer to be able to either post a
patch or suggest a solution unless it is a trivial matter.

> it. I don't have the feeling this is going anywhere. I'd really
> appreciate if you would at least try to help improve things.

I am trying to help improve things.  Do you think I just enjoy lurking
around mailing lists and taking a beating?  I persist because I love
Gentoo, but I see some lemming-like attitudes going on around here and the
users are the ones being led off of cliffs. Yes, I know it is a myth that
lemmings follow each other off of cliffs.

> Btw, the update was announced all over the place, including GWN,
> www.gentoo.org, the forums, etc. You also get a message in the
> postinstall of gcc 3.4.4 iirc.

Which promptly scrolled off of the screen a few days later, never again to
be found unless you know to search for it or read through all of the forums
before doing what the installation handbook describes.
 
> As for the stage 1 problems you described, this is exactly what i
> already told you in the same thread. Supporting stage 1 costs extra
> resources, this thread is a perfect example of it.

And this is the primary point I am arguing.  I keep hearing it, over and
over.  My testing leads me to a much different conclusion, I offered
details describing why I reached my conclusions.  It is the developers that
decided to stop supporting the stage1 installation method, without asking
users.  I am asking you all to justify that decision, preferrably with
facts.  I am claiming that that the stage1 installation method is in fact
much easier, quicker, cleaner, and more dependable.  I have still not heard
a reasonable argument to refute that basic assertion.  I have heard vague
claims but no quantification.

I even went as far as posting patches to fix some of the major bugs that
have gone unnoticed for, how long?  Which is, in effect, me offering
solutions.  I have also posted proposals with patches for simple,
incremental changes in portage that would make gentoo more palatable in an
"enterprise" environment.  

So far it has been a fairly fruitless endeavor...

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MIkey wrote:
> 
>>As for the stage 1 problems you described, this is exactly what i
>>already told you in the same thread. Supporting stage 1 costs extra
>>resources, this thread is a perfect example of it.
> 
> 
> And this is the primary point I am arguing.  I keep hearing it, over and
> over.  My testing leads me to a much different conclusion, I offered
> details describing why I reached my conclusions.  It is the developers that
> decided to stop supporting the stage1 installation method, without asking
> users.  I am asking you all to justify that decision, preferrably with
> facts.  I am claiming that that the stage1 installation method is in fact
> much easier, quicker, cleaner, and more dependable.  I have still not heard
> a reasonable argument to refute that basic assertion.  I have heard vague
> claims but no quantification.
> 
> I even went as far as posting patches to fix some of the major bugs that
> have gone unnoticed for, how long?  Which is, in effect, me offering
> solutions.  I have also posted proposals with patches for simple,
> incremental changes in portage that would make gentoo more palatable in an
> "enterprise" environment.  
> 
> So far it has been a fairly fruitless endeavor...
> 

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.

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.

There is no way around this, in my reckoning, without giving the user a
complete system to start with.  Then they can't trigger silly ass
circular deps, because guess what, the base system is already installed!
  If openSSL depends on perl and perl depends on openSSL, who cares,
they are both installed, not a problem!

- -Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9kB82zglR5RwbyYAQKvZBAAk6NARUbJUy4jnwrGeA2Skod+zduvvKKH
a1/JDbDYTa/zB1zgxyLp28DAT8SBdCjuZ3oaA39txI/ZBgt7QvdtdmrHfWYKOXh2
EI2lGKXsc7f5Boo4SVaMPKYhUcUzLO2c7wuTMTylpL5VHX+JhdFBShCXD6s5CQ3x
glhWWnLBLCAbY0h3PYMwTJKgW+FeD7PMF67RBasYFTxZE5rNFMBv9gOSvZ6Da8oY
mJjBCbXIILcSYHKqPFw7nSHKm9JCRJUAV/kls0GoxqzOEFt5DJyCazPBHAMjflT4
Uw2n0JGIQVy+OREV1iho4S5SjBwLcSeDhs0kXPFL0Kp7GxBjSKO3l5PITp7iXe2F
ubNi5quuG5ElMetPK9bRk+V1m3NYZB+y1m+Ui5ZhsbiRwIvkrrUJbej0gd+SV6Aq
Y9+jAACRfnWFFElSTTkeg5PFrTX3Pq0cuT/XSmt3qFxWwUfqVKNbG3UkIlD05XeQ
VjM/oOaGdw/sWRahzvh2mFKRvRuHESRrByRBjRRqaypbu0lN7MfDwYqXLct2rc89
qFJXNWWisX9vxUDnxZ3OkHZJBQwS+VLy/oL1crhpBH0l45UR/Fzb8l2z5GQfxrrS
88EB7mby4+Owf2ZAgcbAYWOBya2/g9ZbAi/08xv9bYjKZQbyDya8iaEXgzRz3Mui
M0PpX65pkFY=
=xbGa
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

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.
 
> There is no way around this, in my reckoning, without giving the user a
> complete system to start with.  Then they can't trigger silly ass
> circular deps, because guess what, the base system is already installed!
>   If openSSL depends on perl and perl depends on openSSL, who cares,
> they are both installed, not a problem!

Hence you mask the real problem, which will come back and bite you in the
ass again later.  Eventually they will need to switch over to a new
profile, perform a library incompatible gcc/glibc upgrade, etc...

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.

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

[-- 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 --]

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

[MIkey]

Paul de Vrieze wrote:

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

This bug (39318) has persisted since 2004-01-25, with the most recent bite
reported on 2005-12-07.  It is not a problem unique to stage1 or stage3. 
Since portage apparently does not always handle circular dependencies
gracefully, the problem is not solved by a stage3 install, it is deferred.

Regardless, it can more easily be accounted for in bootstrap.sh than tearing
up portage completely.  It still has to be accounted for to build the
official stage3 releases.  Lastly, for some reason I have not run into this
particular problem when building from stage1 for a while now.  

No way?  I get the feeling that anything is possible :)

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Friday 27 January 2006 16:08, MIkey wrote:
> This bug (39318) has persisted since 2004-01-25, with the most recent bite
> reported on 2005-12-07.  It is not a problem unique to stage1 or stage3.
> Since portage apparently does not always handle circular dependencies
> gracefully, the problem is not solved by a stage3 install, it is deferred.

Not deferred, avoided, circumvented. Not the best solution, but it works. 
Stage 1 with the standard useflags does not have the problem either, but with 
some useflags it has. As such many people fail when using stage 1. The reason 
it is no longer suggested in the documentation.
>
> Regardless, it can more easily be accounted for in bootstrap.sh than
> tearing up portage completely.  It still has to be accounted for to build
> the official stage3 releases.  Lastly, for some reason I have not run into
> this particular problem when building from stage1 for a while now.

You have different useflags than others. Yours don't trigger it. Bootstrap.sh 
is for solving the initial bootstrapping interdependencies, not random 
circular dependencies between packages.

Paul

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

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

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

[Wernfried Haas]

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

On Thu, Jan 26, 2006 at 10:42:04AM -0600, MIkey wrote:
> Why I explained a couple of posts further down.  I could not duplicate the
> problem either, I think it went away in 3.4.4-r1.  I don't like posting bug
> reports that I can't duplicate and I prefer to be able to either post a
> patch or suggest a solution unless it is a trivial matter.

So you complain about a problem that is already fixed as if it still
exists? I really don't get it.

> Which promptly scrolled off of the screen a few days later, never again to
> be found unless you know to search for it or read through all of the forums
> before doing what the installation handbook describes.

As said at least 2 times before, why don't you file a bug report to
improve the docs then?

> And this is the primary point I am arguing.  I keep hearing it, over and
> over.  My testing leads me to a much different conclusion, I offered
> details describing why I reached my conclusions.

Your tests are - if i may say so - completely flawed. You disregard
the fact that the basic installation time of stage 3 is much lower
than the one of stage 1. Unpack the bugger, compile a kernel, that's
it. Not much trouble to be expected either - differently to stage 1.

Of course you may spend some time now recompiling stuff with your
favourite CFLAGS and upgrading gcc, but you can do that while your
system is already installed and fully productive (read: watching your
favourite movie or writing mails to gentoo-dev) instead of waiting for
stage 1 to finish. You don't even have to do it immedeately but
whenever you think it's a good time.
Furthermore problems with upgrading gcc after the install are most
likely easier to solve than a bailed out stage 1.

> It is the developers that
> decided to stop supporting the stage1 installation method, without asking
> users.  I am asking you all to justify that decision, preferrably with
> facts.  

Already been discussed a zillion times, please search the archives.

> I am claiming that that the stage1 installation method is in fact
> much easier, quicker, cleaner, and more dependable.  I have still not heard
> a reasonable argument to refute that basic assertion.  I have heard vague
> claims but no quantification.

It simply isn't, it's slower (see above) and more things can break.
If you want hard proof, go search bugzilla, but don't make us do it
for you.

I have to admit i often did stage 1 installs because i found it quite
funny and a good way to test new hardware. Fact is, stage 1 went away
for some reasons and we'll just have to get over it. If you really
care that much about Gentoo as you claim, accept the decisions of the
people behind the stages and try to help improving the supported stage
3 install. 

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[MIkey]

Wernfried Haas wrote:

> So you complain about a problem that is already fixed as if it still
> exists? I really don't get it.

That particular bug was fixed.  Using a stage1/bootstrap approach for a
fresh install is a _method_ of installing gentoo that is immune to that
particular bug because it is a much simpler, more reliable method of
installing gentoo.
 
> Your tests are - if i may say so - completely flawed. You disregard
> the fact that the basic installation time of stage 3 is much lower
> than the one of stage 1. Unpack the bugger, compile a kernel, that's
> it. Not much trouble to be expected either - differently to stage 1.

No, it _can_ be, but is not guaranteed to be.  If you have to upgrade glibc,
for example, it will always take longer.  My tests documented the _exact_
procedure anyone would need to go through to get a system installed,
according to the official handbook, at that point in time.
 
> Furthermore problems with upgrading gcc after the install are most
> likely easier to solve than a bailed out stage 1.

They most certainly are not.
 
> It simply isn't, it's slower (see above) and more things can break.
> If you want hard proof, go search bugzilla, but don't make us do it
> for you.

So what date should we choose to make your statement true?  Cause it ain't
today.  One week after the 2005.1 or 2005.1-r1 stages were released it
might have been, but today it is simply not true.  The reality is that
today it takes twice the time to get the most recent stage3 up to the
current toolchain.  Your assertion might be true for a couple of weeks, a
month at the most.  Depending on what has been moved to stable after the
stage tarball was released.
 
> I have to admit i often did stage 1 installs because i found it quite
> funny and a good way to test new hardware. Fact is, stage 1 went away
> for some reasons and we'll just have to get over it. If you really
> care that much about Gentoo as you claim, accept the decisions of the
> people behind the stages and try to help improving the supported stage
> 3 install.

The stage3 install needs to be ditched for anything other than GRP  or
livecd installs, because face it, that is what it is.  It consists of a
generic system precompiled for desktop use.  The toolchain is literally
years behind most of the other major distributions (nptl and gcc version). 
If users don't want to "waste time compiling" they don't need to be using
gentoo in the first place.

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 18:47, MIkey wrote:
> The stage3 install needs to be ditched for anything other than GRP  or
> livecd installs, because face it, that is what it is.  It consists of a
> generic system precompiled for desktop use.  The toolchain is literally
> years behind most of the other major distributions (nptl and gcc version).
> If users don't want to "waste time compiling" they don't need to be using
> gentoo in the first place.

Mod -1 : trolling

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

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

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 16:34, Mikey wrote:
> You guys have made the decision to stop supporting stage1 installs.  The
> "official" installation method is a stage3.  What I documented, and tested,
> is what you are telling users they have to do.  Download stage3, emerge
> --sync, update system.
>
> The only problem is that you don't actually tell the users what to do when
> there are major issues, such as gcc upgrades.  There is no link in the
> handbook or the gentoo documentation page mentioning the fact that they
> can't just upgrade their gcc without going through the proper process you
> mention above.  What I documented is what any user would _need_ to do to
> get their system installed using your recommended installation method.
>
> And those instructions have nothing whatsoever to do with common sense from
> a new, or even experienced users perspective.  Knowing that a gcc upgrade
> will break libtool is not common sense, nor is it commonly known.

It will not break libtool. It breaks broken libtool files. There should be no 
reason for those files to actually specify libstdc++ at all. The dependency 
is already pulled in by the affected library, so does not need to be 
specified in the libtool file at all.

This goes however to the issue of broken libtool files and broken linking by 
libtool. An entirely different matter and more related to the "--as-needed" 
discussion.

>
> Yes, but I have been called an idiot here for following the instructions
> given to upgrade gcc.  They are not my instructions, they are not the way I
> would do it, they are YOUR instructions.
>
Those are general case instructions, that in this case are making you do extra 
work. If you know what you are doing, like Chris could be expected to, you 
can skip some steps. All that can happen is that you need to remerge some 
package because it doesn't work anymore.

Paul

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

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

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

[Mike Frysinger]

On Thursday 26 January 2006 11:16, Paul de Vrieze wrote:
> On Thursday 26 January 2006 16:34, Mikey wrote:
> > And those instructions have nothing whatsoever to do with common sense
> > from a new, or even experienced users perspective.  Knowing that a gcc
> > upgrade will break libtool is not common sense, nor is it commonly known.
>
> It will not break libtool.

it does and it doesnt

/usr/bin/libtool hardcodes the paths to internal gcc files

normally this isnt an issue as most packages now generate and use their own 
copy of libtool so that they always have the current toolchain information

a few older packages however (jpeg comes to mind) use the system libtool 
instead of bundling their own
-mike
-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 19:48, Mike Frysinger wrote:
> On Thursday 26 January 2006 11:16, Paul de Vrieze wrote:
> > On Thursday 26 January 2006 16:34, Mikey wrote:
> > > And those instructions have nothing whatsoever to do with common sense
> > > from a new, or even experienced users perspective.  Knowing that a gcc
> > > upgrade will break libtool is not common sense, nor is it commonly
> > > known.
> >
> > It will not break libtool.
>
> it does and it doesnt
>
> /usr/bin/libtool hardcodes the paths to internal gcc files
>
> normally this isnt an issue as most packages now generate and use their own
> copy of libtool so that they always have the current toolchain information
>
> a few older packages however (jpeg comes to mind) use the system libtool
> instead of bundling their own

What I mean is that if library X say libjpeg, which uses libstdc++ properly 
links to libstdc++ (ldd libjpeg.so returns libstdc++) there is no need for 
library/binary Y that uses libX to also link against libstdc++. As such there 
is no need to specify this in the libtool archive of library X as linking 
instructions for linking against it. Doing so is superfluous, and the need 
for the "--as-needed" flag in the first place. It is actually also safe to 
just delete the libtool archives. In that case normal linking is performed 
which works perfectly well.

Paul

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

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

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

[Sven Köhler]

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

>> Seems like a bit ranting to me. Why do you use unsupported installation
>> method if you want it simple?
> 
> I don't know about Sven, but the reasons I prefer the "unsupported"
> installation method is all outlined here:

I have no clue, what "bootstrap.sh" is for anymore.
For me, Installing gentoo was always like this:

- you get a minimal system in form of a stage1 tarball
- you then "extend" that system with bootstrap.sh to a system ready for
further emerging
- then you do "emerge -e system" to get a basic gentoo system

I expected the result of these steps to be a "clean" system.

What do i mean with a "clean" system?

Actually i thought, that i mean the result of a "emerge -e system" - but
i know now, that this is not what i mean. For example "emerge -e system"
sometimes choses to install gcc-3.3 instead of the "default" libstdc++-v3.

So what i mean with a "clean" system is a system produced by "emerge -e
system" which acts, as if nothing would have been installed yet.

Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4.
Then he's telling me, that the problem, that Im trying to point out, is
going to vanish with the release of the 2006.0 tarballs. Well, yes,
until the next gcc-slot becomes stable. So the problem is not fixed,
just moved to the future again.

Actually I'm told, that there's no automatic mechanism to get a "clean"
gentoo system. So i'm told, that i have to take a stage3 tarball, and
upgrade it to a clean system.

If i follow that advice, i have to upgrade glibc, gcc, python and
perhaps many more, clean the system from packages in old slots, and then
run an "emerge -e world" (which compiles glibc, gcc, python again).

Pretty much work for a beginnner!
And there's pretty much of experience needed.

Actually, the moment when there's an upgrade to glibc and gcc, than
there's no advantage in taking a stage3 - the whole "upgrading the
stage3"-thing will take as long as using a stage1.
Why? because i have to upgrade glibc and gcc - and that is basically
what bootstrap.sh does too.


Greetings
  Sven


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Wednesday 25 January 2006 21:40, Sven Köhler wrote:
> I expected the result of these steps to be a "clean" system.
>
> What do i mean with a "clean" system?
>
> Actually i thought, that i mean the result of a "emerge -e system" - but
> i know now, that this is not what i mean. For example "emerge -e system"
> sometimes choses to install gcc-3.3 instead of the "default" libstdc++-v3.

what you want to happen just isnt feasible at this point in time (if it ever 
will be)

portage does not automatically change the version of gcc across major 
versions ... this is done on purpose as there is no way of knowing whether 
the user wants the new version of gcc to be the default system one or whether 
they are just installing a new one for fun

you want bootstrap.sh to basically automatically run `emerge gcc && emerge 
prune gcc` ... this is not doable as packages may be tied to the older 
version of gcc ... and in fact, python itself currently links against 
libstdc++, so if bootstrap followed the automated steps listed above, you'd 
end up with a broken python (and thus a broken emerge)

thus, in order to get a "clean" system you're so keen on, you need to run 
bootstrap.sh to get a 3.4 compiler, switch your default compiler to 3.4, 
rebuild anything that is linked against 3.3 with 3.4, prune 3.3 from your 
system, and then continue on with the `emerge -e system`
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Wednesday 25 January 2006 20:40, Sven Köhler wrote:

> Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4.
> Then he's telling me, that the problem, that Im trying to point out, is
> going to vanish with the release of the 2006.0 tarballs. Well, yes,
> until the next gcc-slot becomes stable. So the problem is not fixed,
> just moved to the future again.

> Actually I'm told, that there's no automatic mechanism to get a "clean"
> gentoo system. So i'm told, that i have to take a stage3 tarball, and
> upgrade it to a clean system.

> If i follow that advice, i have to upgrade glibc, gcc, python and
> perhaps many more, clean the system from packages in old slots, and then
> run an "emerge -e world" (which compiles glibc, gcc, python again).
>
> Pretty much work for a beginnner!
> And there's pretty much of experience needed.

Wow, a voice of reason.  That is exactly what I am saying.  Gentoo is unique 
because it it a moving target.  The further in time you move away from an 
official stage3, the worst a stage3 installation method gets.  In fact it 
turns into a outright nightmare.  How long since the last up to date stage 
tarballs?

Solutions?

Release stage tarballs monthly.  If that can't be done, make fixing the 
process so it can be done a priority.

For toolchain updates, a slightly modified bootstrap.sh that builds the 
toolchain in the correct order and whatever is needed to bootstrap portage 
afterwards would be a better approach.  Fix the STAGE1_USE bug, comment out 
CONFIG_PROTECT="-*" and FEATURES="-collision-protect" and you have a 
perfectly reliable method to update the toolchain that takes half the time, 
even on a running system.  This would certainly be more realistic than 
gutting portage so that it installs toolchain packages in the correct order 
so that emerge -e system && emerge -e world is not needed.  Get rid of 
circular dependencies in portage so it can be portable.  Embed its own 
python version so it does not depend on packages with circular 
dependencies.  Do I know absolutely that any of these ideas will work?  
Hell no, but I do know the current installation method sucks depending on 
what time of the year it is, and the answer is not to entrench further in 
an unreliable process.

If nothing else, stop treating users like idiots when they are not, at least 
not all of them, all of the time.

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

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

[Homer Parker]

On Wed, 2006-01-25 at 21:06 -0600, Mikey wrote:
> Solutions?

	And how many have you tested and submitted patches for? Instead of just
complaining, be proactive and help with the problem you perceive is
there. If it's a viable solution, it'll probably be at least discussed.
Then there's a matter of the manpower to maintain said solution. One of
the reasons of going to stage3 as the only supported method is the
ingenious ways users break their systems from stage1, and the overhead
of dealing with bogus bugs.

-- 
Homer Parker
Gentoo/AMD64 Team
Gentoo/AMD64 Arch Tester Strategic Lead
Gentoo Linux Developer Relations
hparker@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Thursday 26 January 2006 00:14, Homer Parker spammed:
> On Wed, 2006-01-25 at 21:06 -0600, Mikey wrote:
> > Solutions?
>
> 	And how many have you tested and submitted patches for? Instead of just
> complaining, be proactive and help with the problem you perceive is
> there. If it's a viable solution, it'll probably be at least discussed.
> Then there's a matter of the manpower to maintain said solution. One of

Yes, I have submitted patches, as well as reported the bugs.  Most often the 
response is that stage1's are going away, you don't know what you are 
talking about, you are an idiot, yadda yadda yadda.

Step one of problem solving is admitting that there is a problem in the 
first place.  I believe there is.

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

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 03:40, Sven Köhler wrote:
> >> Seems like a bit ranting to me. Why do you use unsupported installation
> >> method if you want it simple?
> >
> > I don't know about Sven, but the reasons I prefer the "unsupported"
> > installation method is all outlined here:
>
> I have no clue, what "bootstrap.sh" is for anymore.
> For me, Installing gentoo was always like this:

Ok, let me remind all. Stage 1 is a minimal system that is mainly built 
statically with the sole purpose of being suitable to build a working system 
from. It contains a cripled compiler as one of the first things it does is 
make a proper one. After that the original compiler should be gone. While 
some recompiling is needed because of circular dependencies between libc and 
gcc, this should be no issue. After the bootstrap has been run, one should 
have a proper minimal building environment that should be able to build all 
packages (except for some assumptions on available tools). This minimal 
environment is called stage 2.

Stage 2 should not contain any trace of the bootstrap compiler. If the 
bootstrap compiler was a 3.3.x version and the final one a 3.4.x version, 
there should be no 3.3.x version remaining. Be aware though that if the 
profile does not offer a 3.4 compiler the final will be a 3.3 compiler. If 
desired the profile should be changed before running bootstrap.sh

Because many ebuilds make assumptions about the environment, and because a 
stage 2 will not boot by itself, a number of utilities deemed essential must 
be installed. Those are part of system. The main ingredient being baselayout 
with it's dependencies. Baselayout is what takes care of booting your system 
into a working order.

> Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4.
> Then he's telling me, that the problem, that Im trying to point out, is
> going to vanish with the release of the 2006.0 tarballs. Well, yes,
> until the next gcc-slot becomes stable. So the problem is not fixed,
> just moved to the future again.

If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4 is 
used as the main, that is a bug in the bootstrap script. As such it should be 
fixed. Stage 3 installs just dump a fully functional system, so as such one 
should then just take the steps from the handbook that make it bootable. 
After that the gcc-upgrade guide can be followed, except that world update is 
not really needed, and that world normally also includes system such that 
emerge -e system && emerge -e world is extraneous.

> Pretty much work for a beginnner!
> And there's pretty much of experience needed.

It's easier than going from stage 1. It is possible to skip all the unneeded 
compiling, but it's easy to fuck up, and very hard to explain. That's why 
stage 1 is discouraged.

> Actually, the moment when there's an upgrade to glibc and gcc, than
> there's no advantage in taking a stage3 - the whole "upgrading the
> stage3"-thing will take as long as using a stage1.
> Why? because i have to upgrade glibc and gcc - and that is basically
> what bootstrap.sh does too.

Not really, bootstrap.sh does things in a specific order to take care of 
cyclic dependencies that fail because stage1 is a minimal ( say crippled ) 
environment. But indeed you're better off with a stage3 that is based on a 
current glibc and gcc version. Minor version numbers don't matter much 
though.

Paul

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

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

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

[Sven Köhler]

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

>> I have no clue, what "bootstrap.sh" is for anymore.
>> For me, Installing gentoo was always like this:
> 
> Ok, let me remind all. Stage 1 is a minimal system that is mainly built 
> statically with the sole purpose of being suitable to build a working system 
> from. It contains a cripled compiler as one of the first things it does is 
> make a proper one. After that the original compiler should be gone. While 
> some recompiling is needed because of circular dependencies between libc and 
> gcc, this should be no issue. After the bootstrap has been run, one should 
> have a proper minimal building environment that should be able to build all 
> packages (except for some assumptions on available tools). This minimal 
> environment is called stage 2.
> 
> Stage 2 should not contain any trace of the bootstrap compiler. If the 
> bootstrap compiler was a 3.3.x version and the final one a 3.4.x version, 
> there should be no 3.3.x version remaining. Be aware though that if the 
> profile does not offer a 3.4 compiler the final will be a 3.3 compiler. If 
> desired the profile should be changed before running bootstrap.sh

I think that i clearly explained several times, that bootstrap.sh
installs gcc 3.4 _without_ removing the crippled gcc 3.3 that came with
stage1.

Mike Frysinger is talking about "choice" and ignores me if i tell him,
that the "emerge -e system" uses the crippled gcc 3.3 for the first 10
packages until "emerge -e system" finally rebuilds gcc 3.3 (only due to
some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc
3.3).

>> Mike is telling me, that the 2006.0 tarballs will contain gcc-3.4.
>> Then he's telling me, that the problem, that Im trying to point out, is
>> going to vanish with the release of the 2006.0 tarballs. Well, yes,
>> until the next gcc-slot becomes stable. So the problem is not fixed,
>> just moved to the future again.
> 
> If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4 is 
> used as the main, that is a bug in the bootstrap script. As such it should be 
> fixed.

So i see that you seem to agree with me! The crippled gcc contained in
the stage1 has to be removed by bootstrap.sh - and this is not done
automatically by the steps that bootstrap.sh performs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Thursday 26 January 2006 08:54, Sven Köhler wrote:
> Mike Frysinger is talking about "choice" and ignores me if i tell him,
> that the "emerge -e system" uses the crippled gcc 3.3 for the first 10
> packages until "emerge -e system" finally rebuilds gcc 3.3 (only due to
> some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc
> 3.3).

i didnt ignore you, i told you that's the intended behavior

neither you nor portage changed the compile thus it remained at 3.3
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Sven Köhler]

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

>> Mike Frysinger is talking about "choice" and ignores me if i tell him,
>> that the "emerge -e system" uses the crippled gcc 3.3 for the first 10
>> packages until "emerge -e system" finally rebuilds gcc 3.3 (only due to
>> some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc
>> 3.3).
> 
> i didnt ignore you, i told you that's the intended behavior
> 
> neither you nor portage changed the compile thus it remained at 3.3

So let me summarize that again:

You say, that it's the intended behaviour, that bootstrap.sh keeps the
crippled gcc 3.3 intact and as the default compiler.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Thursday 26 January 2006 13:23, Sven Köhler wrote:
> >> Mike Frysinger is talking about "choice" and ignores me if i tell him,
> >> that the "emerge -e system" uses the crippled gcc 3.3 for the first 10
> >> packages until "emerge -e system" finally rebuilds gcc 3.3 (only due to
> >> some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc
> >> 3.3).
> >
> > i didnt ignore you, i told you that's the intended behavior
> >
> > neither you nor portage changed the compile thus it remained at 3.3
>
> So let me summarize that again:
>
> You say, that it's the intended behaviour, that bootstrap.sh keeps the
> crippled gcc 3.3 intact and as the default compiler.

currently, yes, that is the intended behavior
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Thursday 26 January 2006 13:23, Sven Köhler wrote:
> You say, that it's the intended behaviour, that bootstrap.sh keeps the
> crippled gcc 3.3 intact and as the default compiler.

ok, i looked into this some more and ran some tests ...

long and short of it is that the behavior i discussed before applies only in a 
stage3 and beyond ... the gcc-config logic is specifically tweaked during 
bootstrap and build (i.e. stage1 and stage2), thus everything i said wrt to 
automatic switching of gcc has no bearing on this discussion

ive chatted with wolf and the real fix here is to change the 'emerge clean' at 
the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way 
when you emerge a new SLOT-ed version of gcc, the old stripped down version 
in stage1 is automatically pruned
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Sven Köhler]

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

>> You say, that it's the intended behaviour, that bootstrap.sh keeps the
>> crippled gcc 3.3 intact and as the default compiler.
> 
> ok, i looked into this some more and ran some tests ...
> 
> long and short of it is that the behavior i discussed before applies only in a 
> stage3 and beyond ... the gcc-config logic is specifically tweaked during 
> bootstrap and build (i.e. stage1 and stage2), thus everything i said wrt to 
> automatic switching of gcc has no bearing on this discussion
> 
> ive chatted with wolf and the real fix here is to change the 'emerge clean' at 
> the end of bootstrap.sh into an 'emerge prune sys-devel/gcc' ... that way 
> when you emerge a new SLOT-ed version of gcc, the old stripped down version 
> in stage1 is automatically pruned

I also noticed the "--oneshot" fix.

Thank you!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Sunday 29 January 2006 20:37, Sven Köhler wrote:
> >> You say, that it's the intended behaviour, that bootstrap.sh keeps the
> >> crippled gcc 3.3 intact and as the default compiler.
> >
> > ive chatted with wolf and the real fix here is to change the 'emerge
> > clean' at the end of bootstrap.sh into an 'emerge prune sys-devel/gcc'
> > ... that way when you emerge a new SLOT-ed version of gcc, the old
> > stripped down version in stage1 is automatically pruned
>
> I also noticed the "--oneshot" fix.

i noted this already elsewhere in the thread

dont you read all of the e-mails !?
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Sven Köhler]

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

>> I also noticed the "--oneshot" fix.
> 
> i noted this already elsewhere in the thread
> 
> dont you read all of the e-mails !?

???

I just wanted to say "Thank you" for both fixes.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Mike Frysinger]

On Sunday 29 January 2006 20:50, Sven Köhler wrote:
> >> I also noticed the "--oneshot" fix.
> >
> > i noted this already elsewhere in the thread
> >
> > dont you read all of the e-mails !?
>
> ???
>
> I just wanted to say "Thank you" for both fixes.

sorry i forgot the </joke>
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Thu, 2006-01-26 at 14:54 +0100, Sven Köhler wrote:
> I think that i clearly explained several times, that bootstrap.sh
> installs gcc 3.4 _without_ removing the crippled gcc 3.3 that came with
> stage1.

You are absolutely correct.  We will need to investigate the best
solution for this.  The reason the old compiler is not removed currently
is because of them being in a different SLOT, and therefore protected
from being unmerged by "clean" actions.

> > If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4 is 
> > used as the main, that is a bug in the bootstrap script. As such it should be 
> > fixed.
> 
> So i see that you seem to agree with me! The crippled gcc contained in
> the stage1 has to be removed by bootstrap.sh - and this is not done
> automatically by the steps that bootstrap.sh performs.

I agree also.  I would also like to state that until this email, that I
had no idea that this was what you were describing.

I'll get right on a possible solution.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 14:54, Sven Köhler wrote:
>
> I think that i clearly explained several times, that bootstrap.sh
> installs gcc 3.4 _without_ removing the crippled gcc 3.3 that came with
> stage1.
>
> Mike Frysinger is talking about "choice" and ignores me if i tell him,
> that the "emerge -e system" uses the crippled gcc 3.3 for the first 10
> packages until "emerge -e system" finally rebuilds gcc 3.3 (only due to
> some sideeffects!!! namely the dependy of gcc 3.4 on libstdc++-v3 OR gcc
> 3.3).

Just to make sure, I just performed a stage 1 install in a separate dir. I 
found it did select the new 3.4 compiler. It indeed did not uninstall the old 
compiler, BUT told you to run "emerge -e system" Requiring the whole of 
system to be recompiled. That means everything, including the 3.3 compiler 
according to pretend. Indeed that means you'll end up with a 3.3 compiler 
besides a 3.4 one instead of having a 3.3 libstdc++. If that bothers you, 
just uninstall the 3.3 compiler and be done. It is the crippled compiler that 
doesn't support c++ anyway, ensuring that nothing has been built against 3.3 
libstdc++ yet.

> > If a stage1 install does not remove a 3.3.x bootstrap compiler when a 3.4
> > is used as the main, that is a bug in the bootstrap script. As such it
> > should be fixed.
>
> So i see that you seem to agree with me! The crippled gcc contained in
> the stage1 has to be removed by bootstrap.sh - and this is not done
> automatically by the steps that bootstrap.sh performs.

The crippled gcc will be replaced by the "emerge -e system" that bootstrap.sh 
tells you to perform. As such the system is not broken that much, but 
bootstrap.sh might indeed be "fixed" to special case this situation more. It 
would however require a rebuild of gcc. The reason being that this rebuild 
specifies a dependency on libstdc++3 which then would not be longer provided. 
Binary packages might however assume it's existence (from source will use the 
3.4 libstdc++).

The "way around this" would be to change bootstrap.sh back to building a 
minimal version of the current version that is then used to compile the rest 
of the system, including the C library and gcc itself. Between this however 
the original bootstrap compiler could be removed.

This however goes deep into bootstrapping a linux system. A complicated matter 
that is not for the weak of heart.

Paul

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

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

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

[MIkey]

Paul de Vrieze wrote:

> The "way around this" would be to change bootstrap.sh back to building a
> minimal version of the current version that is then used to compile the
> rest of the system, including the C library and gcc itself. Between this
> however the original bootstrap compiler could be removed.
 
> This however goes deep into bootstrapping a linux system. A complicated
> matter that is not for the weak of heart.

The bootstrap.sh script, with minor bugfixes and perhaps a pause after the
gcc build, is a perfectly working method of bootstrapping gentoo.

Another small fact has been glossed over.  The stage3 method first upgrades
gcc-3.3.5 to gcc-3.3.6, then gcc-3.4.4.  An incredible waste of time that
easily avoided by installing from a stage1 instead of a stage3.  Yes, you
could run bootstrap.sh on a stage3 tarball, but that is not what the
documentation tells the users to do.

As a process to get gentoo installed the stage3 method sucks, period.  There
is absolutely no advantage to it over a stage1 whatsoever.  At certain
times when the stage3 tarball was only released one week previous and there
have been no major upgrades, you might save time.  That is a very limited
window of advantage.  Installing from stage1 narrows down what problems can
happen considerably and would be much easier to support in the long run.

Tell me where I am wrong and why.

Paul I apologize, this is not directed specifically at you, I just had to
find a place to jump in...

-- 
gentoo-dev@gentoo.org mailing list

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

[Wernfried Haas]

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

On Thu, Jan 26, 2006 at 10:17:54AM -0600, MIkey wrote:
> Another small fact has been glossed over.  The stage3 method first upgrades
> gcc-3.3.5 to gcc-3.3.6, then gcc-3.4.4.  

While i can't imagine that, masking 3.3.6 for the time being should
help. And again, why don't you submit a bug report about it, i'm sure
someone would be happy to fix the upgrade guide.

> An incredible waste of time that
> easily avoided by installing from a stage1 instead of a stage3.

If compiling gcc once more is really such a waste of time, you should
consider switching to a binary distribution. ;-)

cheers,
        Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

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

[MIkey]

Wernfried Haas wrote:

> If compiling gcc once more is really such a waste of time, you should
> consider switching to a binary distribution. ;-)

It is not me claiming that using an installation method that compiles gcc
three times makes sense.

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 17:17, MIkey wrote:
> Paul de Vrieze wrote:
> > The "way around this" would be to change bootstrap.sh back to building a
> > minimal version of the current version that is then used to compile the
> > rest of the system, including the C library and gcc itself. Between this
> > however the original bootstrap compiler could be removed.
> >
> > This however goes deep into bootstrapping a linux system. A complicated
> > matter that is not for the weak of heart.
>
> The bootstrap.sh script, with minor bugfixes and perhaps a pause after the
> gcc build, is a perfectly working method of bootstrapping gentoo.
>
> Another small fact has been glossed over.  The stage3 method first upgrades
> gcc-3.3.5 to gcc-3.3.6, then gcc-3.4.4.  An incredible waste of time that
> easily avoided by installing from a stage1 instead of a stage3.  Yes, you
> could run bootstrap.sh on a stage3 tarball, but that is not what the
> documentation tells the users to do.

Running a bootstrap when not bootstrapping is also completely unsupported and 
may give you very strange results. Doing it with less compilation is 
possible, but requires some portage overriding with --nodeps. The 
documentation is mainly supposed to work always, not be the most efficient 
way to do things. 

> As a process to get gentoo installed the stage3 method sucks, period. 
> There is absolutely no advantage to it over a stage1 whatsoever.  At
> certain times when the stage3 tarball was only released one week previous
> and there have been no major upgrades, you might save time.  That is a very
> limited window of advantage.  Installing from stage1 narrows down what
> problems can happen considerably and would be much easier to support in the
> long run.

First of all, the object to be as fast as possible has been dropped as main 
gentoo goal years ago. Stage 3 is indeed based on an old base. It however 
starts you with a working system in which all assumptions made by ebuilds 
about the system are true. This means one should expect a stage 3 to have no 
problems emerging any package. This is not true for a stage 1 or stage 2.

Paul

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

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

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

[MIkey]

Paul de Vrieze wrote:

> First of all, the object to be as fast as possible has been dropped as
> main gentoo goal years ago. Stage 3 is indeed based on an old base. It
> however starts you with a working system in which all assumptions made by
> ebuilds about the system are true. This means one should expect a stage 3
> to have no problems emerging any package. This is not true for a stage 1
> or stage 2.

The expectation of a stage3 having no problems emerging any package is only
true if you don't stray from the preselected desktop-centric USE flags that
were used to build the stage3 in the first place.  When building a suitable
environment for a server, in my case, the very first thing I have to
contend with is blockages and pruning in just the right order.

In my experience, your assumption is reversed.  A build from stage1 does not
run into the problems inherent with a stage3.

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Friday 27 January 2006 15:32, MIkey wrote:
> Paul de Vrieze wrote:
> > First of all, the object to be as fast as possible has been dropped as
> > main gentoo goal years ago. Stage 3 is indeed based on an old base. It
> > however starts you with a working system in which all assumptions made by
> > ebuilds about the system are true. This means one should expect a stage 3
> > to have no problems emerging any package. This is not true for a stage 1
> > or stage 2.
>
> The expectation of a stage3 having no problems emerging any package is only
> true if you don't stray from the preselected desktop-centric USE flags that
> were used to build the stage3 in the first place.  When building a suitable
> environment for a server, in my case, the very first thing I have to
> contend with is blockages and pruning in just the right order.

Would you mind sharing the useflags you mean, and which packages you want to 
build? It might be bugs in the packages involved.

Paul

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

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

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

[MIkey]

Paul de Vrieze wrote:

> Would you mind sharing the useflags you mean, and which packages you want
> to build? It might be bugs in the packages involved.

My standard USE flags for building a lamp server.  No X, no cruft.

USE="-X -alsa -apm -arts -avi -cups -doc -eds -emboss -gnome -gpm -gstreamer
-gtk -gtk2 -imlib -info -ipv6 -kde -mad -man -mikmod -motif -mp3 -mpeg -nls
-ogg -oggvorbis -opengl -oss -pam -qt -quicktime -sdl -vorbis -xmms -xv
apache2 mysql nptl nptlonly php userlocales"

-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Friday 27 January 2006 16:32, MIkey wrote:
> Paul de Vrieze wrote:
> > Would you mind sharing the useflags you mean, and which packages you want
> > to build? It might be bugs in the packages involved.
>
> My standard USE flags for building a lamp server.  No X, no cruft.
>
> USE="-X -alsa -apm -arts -avi -cups -doc -eds -emboss -gnome -gpm
> -gstreamer -gtk -gtk2 -imlib -info -ipv6 -kde -mad -man -mikmod -motif -mp3
> -mpeg -nls -ogg -oggvorbis -opengl -oss -pam -qt -quicktime -sdl -vorbis
> -xmms -xv apache2 mysql nptl nptlonly php userlocales"

Using this flags on a freshly compiled stage3 (from a stage1, just running 
emerge system without setting useflags) I get no blockers at all, when 
setting the useflags at the point that system has been recompiled.

Depclean does suggest removing a number of packages though. Some of which can 
be dangerous to remove (like pam).

I'm sorry, but I can't replicate the problem with regard to merging php for 
these useflags on a fresh stage3.

Paul

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

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

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

[MIkey]

Paul de Vrieze wrote:

> Using this flags on a freshly compiled stage3 (from a stage1, just running
> emerge system without setting useflags) I get no blockers at all, when
> setting the useflags at the point that system has been recompiled.

Are you suggesting that on fresh installs, after editing your use flags, you
should _NOT_ recompile, taking into account the new use flags?  

That is not what the documentation tells you what to do:

"A full description on USE can be found in the second part of the Gentoo
Handbook, USE flags. A full description on the available USE flags can be
found on your system in /usr/portage/profiles/use.desc"

Click on that link to the USE flag section in the handbook:

"If you have altered your USE flags and you wish to update your entire
system to use the new USE flags, use emerge's --newuse option:

emerge --update --deep --newuse world"

> I'm sorry, but I can't replicate the problem with regard to merging php
> for these useflags on a fresh stage3.

Follow the instructions in the official handbook to replicate the problem,
what any new user to gentoo would need to go through.

-- 
gentoo-dev@gentoo.org mailing list

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

[MIkey]

Paul de Vrieze wrote:

> Using this flags on a freshly compiled stage3 (from a stage1, just running
> emerge system without setting useflags) I get no blockers at all, when
> setting the useflags at the point that system has been recompiled.
> 
> Depclean does suggest removing a number of packages though. Some of which
> can be dangerous to remove (like pam).
> 
> I'm sorry, but I can't replicate the problem with regard to merging php
> for these useflags on a fresh stage3.

On second thought, never mind :)  I am not sure what you are trying to point
out here in the first place.

-- 
gentoo-dev@gentoo.org mailing list

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

[Stephen P. Becker]

MIkey wrote:
> Paul de Vrieze wrote:
> 
>> Using this flags on a freshly compiled stage3 (from a stage1, just running
>> emerge system without setting useflags) I get no blockers at all, when
>> setting the useflags at the point that system has been recompiled.
>>
>> Depclean does suggest removing a number of packages though. Some of which
>> can be dangerous to remove (like pam).
>>
>> I'm sorry, but I can't replicate the problem with regard to merging php
>> for these useflags on a fresh stage3.
> 
> On second thought, never mind :)  I am not sure what you are trying to point
> out here in the first place.
> 

He is trying (quite successfully) to show that you are full of shit.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

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

[Mikey]

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

On Saturday 28 January 2006 12:39, Stephen P. Becker wrote:

> > On second thought, never mind :)  I am not sure what you are trying to
> > point out here in the first place.
>
> He is trying (quite successfully) to show that you are full of shit.

In this particular case, I might have to agree with you Steve.  He was 
actually confirming what I have been saying all long.

So thanks for gracing me with your brilliant, well reasoned insights.  
Always nice to know that when I make an ass of myself, you will be there to 
let me know...

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

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

[Chris Gianelloni]

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

On Thu, 2006-01-26 at 03:40 +0100, Sven Köhler wrote:
> Pretty much work for a beginnner!

...and?

You're using a source-based distribution.  It is not designed for the
beginner insomuch as you have to perform maintenance tasks that would
otherwise be unnecessary in a binary-only distribution.

> And there's pretty much of experience needed.

Yes, there is.  There's also the ability to follow the directions given
by ebuilds when they're merged.

> Actually, the moment when there's an upgrade to glibc and gcc, than
> there's no advantage in taking a stage3 - the whole "upgrading the
> stage3"-thing will take as long as using a stage1.

Not quite.

> Why? because i have to upgrade glibc and gcc - and that is basically
> what bootstrap.sh does too.

...and headers, and portage, and baselayout, and binutils, and texinfo,
and zlib, and ncurses...

Something else that *everybody* seems to be missing is that the *first*
method in the GCC upgrading guide, which is the one that would apply
from a fresh-installed system, seems to be completely overlooked by all
the naysayers.  Funny how if someone actually read the entire document,
they'd see just how much of their own time they're wasting.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Mikey]

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

On Thursday 26 January 2006 08:12, Chris Gianelloni spammed:

> Something else that *everybody* seems to be missing is that the *first*
> method in the GCC upgrading guide, which is the one that would apply
> from a fresh-installed system, seems to be completely overlooked by all
> the naysayers.  Funny how if someone actually read the entire document,
> they'd see just how much of their own time they're wasting.

Have you even read the bug reports and forum threads on upgrading gcc via 
that method?

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

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

[Paul de Vrieze]

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

On Thursday 26 January 2006 16:40, Mikey wrote:
> On Thursday 26 January 2006 08:12, Chris Gianelloni spammed:
> > Something else that *everybody* seems to be missing is that the *first*
> > method in the GCC upgrading guide, which is the one that would apply
> > from a fresh-installed system, seems to be completely overlooked by all
> > the naysayers.  Funny how if someone actually read the entire document,
> > they'd see just how much of their own time they're wasting.
>
> Have you even read the bug reports and forum threads on upgrading gcc via
> that method?

Well, with my just completed stage 1, I can tell you that there is absolutely 
no binary on the system that actually links to libstdc++. As such the result 
of using revdep-rebuild is absolutely zip. This means you can actually skip 
that whole step. Be aware though that this is with the current x86-2005.1-r1 
stage1 and x86-2005.1 profile, and may or may not be true in the future.

As such you can just run 
# emerge --oneshot sys-libs/libstdc++-v3
# emerge -aC =sys-devel/gcc-3.3*
as suggested. You could even leave out the first step as it's not absolutely 
essential. It's more of a know what you're doing thing though.

Paul

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

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

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

[MIkey]

Jan Kundrát wrote:

> As the person who did the fixes for most of the bugs reported against
> the GCC Upgrading Guide, I'd say that I'd remember about that "bug
> reports on upgrading gcc"... Could you please refresh my memory by
> providing bug numbers in Gentoo Bugzilla? Were such issues reported to
> us at all?

http://bugs.gentoo.org/show_bug.cgi?id=114341

-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

MIkey wrote:
> http://bugs.gentoo.org/show_bug.cgi?id=114341

Have you noticed that I'm the reporter of this bug? Just FYI, bug
*wasn't* in the guide but in the underlying eclass/gcc-config causing
automatic switch to newly installed GCC during pkg_postinst. Just by a
coincidence the eclass was updated shortly after gcc/3.4 stabilisation.

BTW, you used the term "bugs" which is plural form...

TIA,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[MIkey]

Jan Kundrát wrote:

> Have you noticed that I'm the reporter of this bug? Just FYI, bug
> *wasn't* in the guide but in the underlying eclass/gcc-config causing
> automatic switch to newly installed GCC during pkg_postinst. Just by a
> coincidence the eclass was updated shortly after gcc/3.4 stabilisation.

A bug, again, that the stage1 installation method was immune to, which is
the topic at hand.  Not who reported what when.  I found that bug when it
hit me and noticed that it had been reported.  I thanked the Gods that you
were working on it, that I hadn't attempted to upgrade a production box,
and went about my business avoiding it by installing from stage1.

-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

MIkey wrote:
> A bug, again, that the stage1 installation method was immune to,

How come? (I'm not familiar with toolchain.eclass at all.)

> which is
> the topic at hand.  Not who reported what when.  I found that bug when it
> hit me and noticed that it had been reported.  I thanked the Gods that you
> were working on it, that I hadn't attempted to upgrade a production box,
> and went about my business avoiding it by installing from stage1.

Aaaargh. You've mentioned "bug reports [...] on upgrading gcc via that
method". Got anything apropriate?

-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[MIkey]

Jan Kundrát wrote:

> MIkey wrote:
>> A bug, again, that the stage1 installation method was immune to,
> 
> How come? (I'm not familiar with toolchain.eclass at all.)

Because the first pass of the bootstrap, that prepares a working gcc/glibc,
uses the bootstrap USE flag and disables all but a few other basic USE
flags.  There is no previous built in dependency problems once you
correctly get past that bootstrap phase.  It is already assumed that you
are upgrading to the latest toolchain during bootstrap.
 
> Aaaargh. You've mentioned "bug reports [...] on upgrading gcc via that
> method". Got anything apropriate?

Not following you...

-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

MIkey wrote:
>>>A bug, again, that the stage1 installation method was immune to,
>>
>>How come? (I'm not familiar with toolchain.eclass at all.)
> 
> 
> Because the first pass of the bootstrap, that prepares a working gcc/glibc,
> uses the bootstrap USE flag and disables all but a few other basic USE
> flags.  There is no previous built in dependency problems once you
> correctly get past that bootstrap phase.  It is already assumed that you
> are upgrading to the latest toolchain during bootstrap.

How are USE flags related to the operation of toolchain.eclass,
especially calling `gcc-config`?

>>Aaaargh. You've mentioned "bug reports [...] on upgrading gcc via that
>>method". Got anything apropriate?
> 
> 
> Not following you...

You stated that there are some bugreports from users having troubles
with the upgrade guide, especially when following the quicker method.
Still waiting for them.

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[MIkey]

Jan Kundrát wrote:

> MIkey wrote:
>>>>A bug, again, that the stage1 installation method was immune to,
>>>
>>>How come? (I'm not familiar with toolchain.eclass at all.)

Because the stage1 method bootstraps gcc/glibc and performs the minimum
steps needed to complete the subsequent emerge -e system.  The dependencies
on having the old gcc still available are not there because the packages
have not been built yet.  You can purge the old gcc immediately after it
upgrades instead of after the entire system completes.

Take your pick:
http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=revdep&field0-0-1=component&type0-0-1=substring&value0-0-1=revdep&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=revdep&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=revdep


-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

MIkey wrote:
> Because the stage1 method bootstraps gcc/glibc and performs the minimum
> steps needed to complete the subsequent emerge -e system.  The dependencies
> on having the old gcc still available are not there because the packages
> have not been built yet.  You can purge the old gcc immediately after it
> upgrades instead of after the entire system completes.

You haven't answered my question. Doesn't matter as I'm not going to
waste anyone's time with this thread. Feel free to replay, you won't
hear anything back, at least not from me.

> Take your pick:
[..]

Those are bugs against the revdep-rebuild package.

Please stop responding to this thread. We won't reach the consensus as
the half of existing Gentoo developers already think that you're (and
excuse me for this word) an asshole. I really don't care.

Have a nice day,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

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

[Paul Varner]

On Thu, 2006-01-26 at 16:55 -0600, MIkey wrote:
> Jan Kundrát wrote:
> 
> > Those are bugs against the revdep-rebuild package.
> 
> Which is one of the suggested methods to migrate gcc.  Not necessary from
> stage1...

How does the listing of revdep-rebuild bugs have anything to do with
this topic? None of those bugs are relevant to either a stage 1 install,
stage 3 install, or gcc upgrade.

Regards,
Paul

-- 
gentoo-dev@gentoo.org mailing list

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

[Jakub Moc]

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


26.1.2006, 23:02:28, MIkey wrote:

> You can purge the old gcc immediately after it upgrades instead of after
> the entire system completes.

How the fsck does it matter? What's your obsession here??? So purge it and
stop this finally, you have a freedom to purge it and you have a freedom to
not use stage1 and you have a freedom to not use Gentoo at all, ktnxbye.

> Take your pick:
> http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=revdep&field0-0-1=component&type0-0-1=substring&value0-0-1=revdep&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=revdep&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=revdep

Eh???


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 23:27 +0100, Sven Köhler wrote:
> IMHO, i would expect that "/usr/portage/scripts/bootstrap.sh; emerge -e
> system" results in a system, that has a certain "integrity" with a
> minimum of manual steps. (gentoo install being as easy as possible)

That has never been the case.  The entire *point* of bootstrap is so
that you can *customize* the system.  If you're doing
"/usr/portage/scripts/bootstrap.sh; emerge -e system" with no
customization, you're wasting your time.  You get identical results from
a "stage3 tarball + edit make.conf + emerge -e system + emerge -v
depclean", and it is a faster method, too.

> At the moment, "/usr/portage/scripts/bootstrap.sh; emerge -e system"
> produces a system, that is IMHO unexpected for most users.

This is exactly why we do not recommend a stage1 installation to anyone
that is unwilling to do work to modify the installation themselves.
Using stage1 assumes that you know what you are doing.

> That's not a problem for me. So excuse me that i wanted
> gentoo-installation to be more simple.

It is quite simple.  The documentation is quite extensive on installing
from a stage3 tarball.  How much simpler can you get? ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 13:30 +0100, Sven Köhler wrote:
> Hi,
> 
> bootstrap.sh installs gcc 3.4! So far so good, but gcc 3.3 is not
> unmerged. The consequence is, that "emerge -e system" installs gcc 3.4
> and then afterwards gcc 3.3 instead of libstdc++-v3.
> 
> I'd like to see, that bootstrap.sh unmerges any old gcc
> (emerge -C \<${gcc package that we just compiled})
> so that a clean system is built with gcc 3.4 only!

Nope.  We don't want to remove that choice from the user.  We are
working now towards the 2006.0 release, which means GCC 3.3 will not be
present in the stage1 tarball.  Basically, wait for 2006.0, or follow
the standard steps to switch compilers yourself.  It's not like we're
forcing you to keep both compilers.  ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Sven Köhler]

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

>> I'd like to see, that bootstrap.sh unmerges any old gcc
>> (emerge -C \<${gcc package that we just compiled})
>> so that a clean system is built with gcc 3.4 only!
> 
> Nope.  We don't want to remove that choice from the user.  We are
> working now towards the 2006.0 release, which means GCC 3.3 will not be
> present in the stage1 tarball.  Basically, wait for 2006.0, or follow
> the standard steps to switch compilers yourself.  It's not like we're
> forcing you to keep both compilers.  ;]

As i wrote in my other post:
there is no choice! boostrap.sh does what it does:
- installs gcc 3.4
- leaves the gcc 3.3 from the stage1 tarball unchanged

So actually the first packages compiled by "emerge -e system" are
compiled with the gcc 3.3 which came with the stage1 tarball.
And that "emerge -e system" updates gcc 3.3 - well, that is only a
side-effect of other things!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 22:09 +0100, Sven Köhler wrote:
> >> I'd like to see, that bootstrap.sh unmerges any old gcc
> >> (emerge -C \<${gcc package that we just compiled})
> >> so that a clean system is built with gcc 3.4 only!
> > 
> > Nope.  We don't want to remove that choice from the user.  We are
> > working now towards the 2006.0 release, which means GCC 3.3 will not be
> > present in the stage1 tarball.  Basically, wait for 2006.0, or follow
> > the standard steps to switch compilers yourself.  It's not like we're
> > forcing you to keep both compilers.  ;]
> 
> As i wrote in my other post:
> there is no choice! boostrap.sh does what it does:
> - installs gcc 3.4

Only because it is unmasked.  You could always mask 3.4 to keep it from
installing.  Yes, this is your choice.

> - leaves the gcc 3.3 from the stage1 tarball unchanged

You could also remove 3.3 after doing your bootstrap.  Remember that
part in the Handbook that says you really shouldn't be playing around
with bootstrap if you don't know what you're doing and willing to do
work on your own system?  Here's a prime example.

> So actually the first packages compiled by "emerge -e system" are
> compiled with the gcc 3.3 which came with the stage1 tarball.

Again, this is completely because of you not making any changes on your
system.

> And that "emerge -e system" updates gcc 3.3 - well, that is only a
> side-effect of other things!

Which you won't have to deal with for long, 2006.0 is being worked on as
we speak.  The basic jist of this is that what you are seeing is pretty
much expected behavior for bootstrapping using a stage with an older
GCC.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[MIkey]

Chris Gianelloni wrote:

> Which you won't have to deal with for long, 2006.0 is being worked on as
> we speak.  The basic jist of this is that what you are seeing is pretty
> much expected behavior for bootstrapping using a stage with an older
> GCC.

The way I read it, the gcc-3.4.4-r1.ebuild includes a dependency on
libstdc++-v3 and =sys-devel/gcc-3.3* if "build" is not in your USE
environment.  The bootstrap during bootstrap.sh sets that build flag.  Any
subsequent installs of gcc-3.4.4-r1 are going to install libstdc++-v3, no
matter what you do (at least x86 users).  Or maybe I am just reading that
PDEPEND wrong.

Regardless, I have never had to mask out lower versions of gcc before.  I
assumed the reason for the dependency was a half ass attempt to keep idiots
from thoughtlessly destroying their toolchain.

-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 16:31 -0600, MIkey wrote:
> The way I read it, the gcc-3.4.4-r1.ebuild includes a dependency on
> libstdc++-v3 and =sys-devel/gcc-3.3* if "build" is not in your USE
> environment.  The bootstrap during bootstrap.sh sets that build flag.  Any
> subsequent installs of gcc-3.4.4-r1 are going to install libstdc++-v3, no
> matter what you do (at least x86 users).  Or maybe I am just reading that
> PDEPEND wrong.

You're reading it wrong.  The bootstrap USE flag is set during
bootstrap, not the build USE flag.  This means libstdc++-v3 (or gcc 3.3)
is required at the bootstrap level.  The reason that libstdc++-v3
doesn't get pulled into bootstrap is because gcc 3.3 is already
installed.  If you take a stage1 that was built with gcc 3.4, such as
the builds I have been testing which will eventually become 2006.0, you
will find that libstdc++-v3 is pulled into bootstrap, as expected.  In
the future, the dependency will be removed from gcc, as it is being
transitioned off to packages that require it instead.

> Regardless, I have never had to mask out lower versions of gcc before.  I
> assumed the reason for the dependency was a half ass attempt to keep idiots
> from thoughtlessly destroying their toolchain.

Perhaps it was to support binary packages that were linked against the
older libstdc++ library?  Like I said, these packages are having their
dependencies updated to give a better dependency tree.  Once that is
done, the dependency will be removed some time after this release is out
the door.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[MIkey]

Chris Gianelloni wrote:

> You're reading it wrong.  The bootstrap USE flag is set during
> bootstrap, not the build USE flag.  This means libstdc++-v3 (or gcc 3.3)
> is required at the bootstrap level.  The reason that libstdc++-v3

My mistake, it is just portage that gets that build flag during
bootstrapping.  Just out of curiosity, what does utilize the "build" flag,
other than portage during bootstrapping?
 


-- 
gentoo-dev@gentoo.org mailing list

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

[Chris Gianelloni]

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

On Wed, 2006-01-25 at 17:50 -0600, MIkey wrote:
> Chris Gianelloni wrote:
> 
> > You're reading it wrong.  The bootstrap USE flag is set during
> > bootstrap, not the build USE flag.  This means libstdc++-v3 (or gcc 3.3)
> > is required at the bootstrap level.  The reason that libstdc++-v3
> 
> My mistake, it is just portage that gets that build flag during
> bootstrapping.  Just out of curiosity, what does utilize the "build" flag,
> other than portage during bootstrapping?

It is used in building the stage1 tarball itself.  All of the packages
that have the build USE flag have it because it reduces functionality in
the package to just what is needed for bootstrap to complete for the
stage1 tarball.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]