Gentoo Archives: gentoo-ppc-dev

From: Pieter Van den Abeele <pvdabeel@g.o>
To: gentooppc-dev@g.o
Subject: Re: [gentooppc-dev] ARCH=ppc in unified portage and some downfalls
Date: Mon, 10 Jun 2002 05:00:30
In Reply to: Re: [gentooppc-dev] ARCH=ppc in unified portage and some downfalls by Owen Stampflee

On Sun, 9 Jun 2002, Owen Stampflee wrote:

> Well, as I have said in IRC, I believe that creating a new rsync tree > would fix things for the moment. We could always have a testing tree for > those who want to use err test, err blow up their systems with the > latest packages.
> Debian does it this way, keeping all the different archs seperate. With > a binary packaging method it has to be done this way so why isnt this > done when the packages are in source form? This would solve little > problems such as xforms and we could also fix other little things which > say they require nasm but don't really need it. > > In the future it would be great if portage could do this automagically. > It could look at the arch and then pull from the correct tree. > > Owen
Gentoo is not Debian :-) When GentooPPC was born it had it's own CVS and rsync, because of this, there was a lot of QA (which seems to be a major factor now): GentooPPC CVS (and rsync) was about a week 'behind' on x86 CVS. There were a few major problems: 1) Ebuilds could be broken on both PPC and x86, when x86 devs introduced a rewrite/cleanup, it had to be manually imported on PPC. Most of the time ppc devs don't know when a bugfix is introduced to x86 portage, so it happened often that ppc users reported a bug already fixed on x86. 2) If an ebuild is fixed on PPC, it has to be introduced to x86 at the same time. Introducing stuff to x86 shouldn't happen without testing on x86, if the x86 part stopped working, it needs to get fixed, and the fixed x86 ebuild may stop working on ppc ... Combined with another arch merging its stuff at the same time, makes life very interesting: ppc stuff is fixed against x86 ebuilds, if for example sparc introduced a fix to x86, the ppc fix is rendered invalid, and has to be completely rewritten to accomodate the sparc fix. Of course this caused ppc patches to be added to x86 often without testing. The merge into x86 could introduce a few problems: a newer release may have been introduced on x86 or the x86 ebuild may have had some other things fixed, the newer ebuilds have to be merged into PPC, fixed and tested again and again, until the ebuild on ALL platforms works. Most ppc guys don't have a x86 and a sparc at home to test. (I have only an x86 which is running Gentoo) 3) While an ebuild might look the same, it may be different on two platforms. Finding out which one is newer is easy to do, making sure the newest ebuild works on both platforms requires testing. 4) Importing stuff from x86 into PPC portage (syncing the two) is almost impossible to do with CVS (It will still remain more or less impossible when we start using bitkeeper for example) 5) Fixes introduced by the PPC platform in X86 may be 'forgotten' in newer releases on x86. No x86 dev is able to test the ppc fix, so ppc fixes might seem unnecessary... 6) x86 devs tend to shit ebuilds directly into x86 portage 7) Every day new ebuild features get added to portage: new USE vars, old USE vars get removed, new SLOT var, new LICENCE var, ebuild indentation rules... I have no problem with introducing and removing features, or even rewriting the whole portage stuff, but it is almost impossible to merge stuff between trees when these things happen. That's why I want to keep a single tree containing all. This way ppc fixes get fo Keeping a separate repository for all archs might seem a good idea, it isn't because this will cause gentoo to fall apart, and multiplies all work by 5 and might even render the work unusable after all. Debian may be able to use separate trees, but there are a lot more devs working on Debian and I chose Gentoo because Debian would rather fix old packages than introduce new ones. I want to be on the edge, and compile everything from source, but this doesn't mean Gentoo cannot be as stable like debian-stable. With Gentoo stability is achieved by emerging a basic system, and emerging newer ebuild releases when critical bugs are detected in the software merged by the ebuild (this can be done using a profile, but the profile has to be maintained). Gentoo needs to do QA by <<<testing>>> more before releasing. No more: voila, it's in portage, please try it out But: voila, it's in portage, unmask it (merge with -unstable or whatever) and it will be unmasked when it's tested by a few people. I'm sure we will see a Gentoo-stable solution soon. But please bear in mind that Gentoo is an all-in-one solution and I think it should stay that way. A linux distro can be stable and on the edge at the same time, it's up to the user to choose what ebuilds he likes, just like debian, but with a single repository for all archs, this allows people to be on the edge on all platforms and allows devs to concentrate on testing instead of merging untested. This doesn't mean there can't be a Gentoo-stable (profile or whatever) on all archs.
> problems such as xforms and we could also fix other little things which > say they require nasm but don't really need it.
Due to some techical failure on one of my critical boxes, I have been away a while, so I'm not up to speed with what happened with xforms and other related discussions. I guess that ebuilds that require nasm but don't really need it can have the nasm dependency removed. (or it should be merged with nasm use flag removed, if a nasm flag exists) It reminds me of the vim problem that had X as a dependency, mergin vim meant merging X. It should be split up into two ebuilds or you should be able to disable the X compilation dependency by removing the X useflag. If the ebuild is really broken, it can be masked out in the profile (just like lilo for example, which has no use on ppc), until some ppc dev rewrites the ebuild or patched it. Pieter -- Pieter Van den Abeele pvdabeel@××××××.be - pvdabeel@g.o
> -- > Owen Stampflee - owen@××××××××××.org > > > _______________________________________________ > gentooppc-dev mailing list > gentooppc-dev@g.o > >