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

Hi Pieter

Well i can see your points on things, but here\'s where the single
biggest porblem lies. The x86 gentoo had no less than 22 updated ebuilds
comitted last week, of which only ONE was tested on ppc (Azarah is good
for that - he asked me to test it) becuase it containted some very long
awaited PPC fixes (was the scrollwheel fix for xfree).  This also bring
to point the fact that this build _just_ made it live with some crucial
ppc fixes after weeks of waiting.

It is still my opinion that a unified tree is going to cause many many
many problems in the very near future (like with GCC 3.1).  No offence
to the gentoo folk but there are truly some _bad_ x86 developers
comitting completely untested code and unmasking things that just
shouldn\'t be.

For example I did an updated qt-copy snapshot build last week w/ fixes
for both ppc and x86, and I put it up for testing (masked), the
maintainer unmasked it within one hour of when I committed it with no
testing and it broke things for some people because of this.  It makes
us (me) look bad, it was a simple fix that and I got in it right away,
but you see where things are leading to here...

There are _very_ many things in the current portage which have a lot of
x86 specific stuff in them (i.e. tweaked config files, x86 only
patche,s, etc) and honestly i don\'t think that we can either rely onthe
x86 devs to test things against ppc, nor should they really have to in a
perfect world.

portage really really needs something better than if [ ${ARCH} = \"ppc\"
] for the environment.  As for the xforms fiasco i can fill you in in
private, but hold on to your shorts, its a _very_ nasty problem that is
not likely to get resolved in the near future.

My biggest concern is there will be much fighting between x86 peeps and
ppc peeps to make things happen, in the last few weeks since you
haven\'t been around the x86 portage has literally exploded with new
builds, and if you go to the #gentoo channel at all it appears that
there are a LOT of broken things.  In fact on my x86 box right now (even
with cvs tree) there are a lot of things that just plain don\'t work,
and becuase of this the ppc version of things will also be broken.

I also posted this message to gentoo-core (are you a member of that
list?) and got at least an answer from drobbins.  I think we will ahve
to work with him on getting portage a lot more ARCH friendly, or we are
going to have a lot of problems getting things done.

havin x86 and ppc within the exact same file is a nightmare from where i
see it, but if that is the way things need to be then that is how it
will be I guess.  PPC != x86 for maturity level or code compatability. 
i would love to see a .ppc.ebuild file as a seperate entity, but that\'s
just me.  it would solve many problems.

I also think that one of the first things we have to do with the ppc
portage is to mask ot _everything_ that is in x86 portage, and then
proceed to unmaks only certified things that work.  There are still many
things in portage that might not work, but no ones knows as they have
probably not even been tried on ppc to this point in time.

I honestly think that Gentoo needs some \'port\' managers, I.E. people
doing QA that can verify that things are proper before things actually
get comitted to the public portage, it doesn\'t make sense any other
way.  Right now peeps can commit wahtever they want and within 30
minutes it\'s live!  That is scary as ehll from where i see it...for
example someone accidentily comitted their hacked up packages.mask file
which opened up a whole bevy of stuff to the world and it went for a day
before anyone noticed it (eeeeeek).

Gerk

P.S. i think we are trying to get an IRC meeting toegether of the PPC
peeps, we did it last week as well, but had a poor turnout :( (3 peeps
were there).  i think that we should try and get this going ASAP and
also invite drobbins in (i think he discussed wanting to meet with us on
IRC as well).

P.S.S.  If you would like to test some things I can arrange a shell
account for you on a PPC box and give you root access until you are up
and running again.  Email me privately if you want this :)


On 06-10-2002 06:00 am, you wrote:

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