Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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
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... pgpIbicruU0Lj.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp4nMP5IepCB.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpoPs7I4mxpc.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpRmG8Mm0ZZu.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDfield0-0-0=producttype0-0-0=substringvalue0-0-0=revdepfield0-0-1=componenttype0-0-1=substringvalue0-0-1=revdepfield0-0-2=short_desctype0-0-2=substringvalue0-0-2=revdepfield0-0-3=status_whiteboardtype0-0-3=substringvalue0-0-3=revdep Eh??? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpcj9z9V3tLh.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
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
