Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-ppc-dev
Navigation:
Lists: gentoo-ppc-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentooppc-dev@g.o
From: Pieter Van den Abeele <pvdabeel@g.o>
Subject: Re: ARCH=ppc in unified portage and some downfalls
Date: Mon Jun 10 16:16:03 2002
On Mon, 10 Jun 2002 mguertin@... wrote:

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

We can use our own profile to solve this problems.

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

The cracklib ebuild I fixed a while ago, was a very good example of how
bad some ebuilds are written. It almost seemed to me that nobody actually
knew what the stuff did.

We have too much devs maintaining "fun" parts, and only a few (5) guys
trying to maintain critical ebuilds. IMHO gentoo has exploded that much in size
that it definately needs to 'hire' some more fulltime devs.

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

As long as the x86 devs don't start removing ppc stuff, I'm happy :-)

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

Can you please explain this problem to me in a few lines, I cannot imagine
it being such a big problem.

> My biggest concern is there will be much fighting between x86 peeps and
> ppc peeps to make things happen,

My motto is: try to avoid breaking things and tell maintainers.
If they prefer to rewrite your fix, make them email you and ask them to
test it :-)

> I also posted this message to gentoo-core (are you a member of that
> list?)

yes, I've read your emails and I've send a reply

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

I like the solution drobbins proposed (with a little tweaking)

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

We had a long discussion about this on gentoo-alt, and at the time it
seemed that the ARCH stuff would be

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

It is possible to use separate ARCH files using eclasses. Check gentoo-alt
logs. But in some cases separate files would be better. I even suggested a
portage painting system so that x86 platforms only download x86 ebuilds
etc. (This can in fact easily be combined with the GROUPS stuff)

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

Masking everything seems a bit drastic to me.

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

A lot of stuff hasn't been tried on ppc: by the time the stuff is
compiled, a new release is ready.

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

Yes, I also think Ebuild categories should be appointed to certain
maintainers responsible for that category. They should be supervising the
changes made to their section.

> Right now peeps can commit wahtever they want and within 30
> minutes it\'s live!

I don't know if I've already suggested this; but it might be a good idea
to have a daily/weekly/monthly snapshot mirror. People could try to get
things fixed by snapshot time.

> 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

hehe, the whole point of using a transaction - commit system is to prevent
changes like this. It's a good thing things can be undone relatively easy.

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

I have a nasty timezone problem (I'm asleep when everybody is awake, so
IRC is not very usefull to me) I do try to be on IRC when I'm not working
and I can afford to spend whole nights on irc. Just send me an email if
you like me to attend a irc meeting, I won't be on IRC this month because
of a system crash (my gentoo dev box is toast) and I'm having exams. :-(

> 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 :)

That would be very nice, I'll send you an email asap.

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


Replies:
Re: ARCH=ppc in unified portage and some downfalls
-- Mark Guertin
References:
Re: ARCH=ppc in unified portage and some downfalls
-- mguertin
Navigation:
Lists: gentoo-ppc-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: ARCH=ppc in unified portage and some downfalls
Next by thread:
Re: ARCH=ppc in unified portage and some downfalls
Previous by date:
Re: ARCH=ppc in unified portage and some downfalls
Next by date:
Re: [gentoo-core] ARCH=ppc in unified portage and some downfalls


Updated Jun 17, 2009

Summary: Archive of the gentoo-ppc-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.