Re: [gentooppc-dev] ARCH=ppc in unified portage and some downfalls

[Pieter Van den Abeele]

Hi,

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
> http://penguinppc.org/~owen
>
> _______________________________________________
> gentooppc-dev mailing list
> gentooppc-dev@g.o
> http://lists.gentoo.org/mailman/listinfo/gentooppc-dev
>