On Monday 10 June 2002 16:15, Pieter Van den Abeele wrote:
> 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.
Yep, I have seen many cases of this throughout some builds. Other builds are
excellent, and many are between.
> As long as the x86 devs don't start removing ppc stuff, I'm happy :-)
only happened once AFAIK ;)
> Can you please explain this problem to me in a few lines, I cannot imagine
> it being such a big problem.
It's a long explanation (i posted a bit of it to -core) and I think I have a
workaround for it now (albeit not very elegant but it should work).
> 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 :-)
Yep, I've followed protocol to date ;)
> We had a long discussion about this on gentoo-alt, and at the time it
> seemed that the ARCH stuff would be
It may yet still be great, IMHO its just more difficult to manage the
possibility of arch's being split across files, etc than it is to manage
duplicate (or near duplicate) files...but the more i think of the
possibilities the more I like daniels solution with group masking as well
> 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 think even something as simple as the ability to have say foo-1.0.ebuild and
(if neccesary to override anything drastic like a whole seperate build)
foo-1.0-ppc.ebuild. This could also allow the ability to name
foo-10.-ppc.ebuild as a ppc only ebuild (or vica versa for another arch).
This may become more relevant when a 3rd arch is introduced as well.
> Masking everything seems a bit drastic to me.
Yes, maybe you are right. But I think that we shold at least try to compile a
list on known 'working' builds and masking out everything else. I imagine
there are a great many builds that just aren't going to work on ppc right
now. Then as builds are known working we could add them (and unmask). Or
even possibly just maintain a list of known workin builds on the website
somewhere...some kind of clue. It was kind of comical trying to explain why
vmware wouldn't work on someone's ppc, they just weren't taking no for an
answer (more obvious ones are now currently masked).
> 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.
Yes, that would be very very good I think too.
> 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.
I think that would be nice too, and it would prevent most accidental or
improperly masked builds to get into the wild.
> 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. :-(
Hmmm, yes i can see this being a bit difficult, I believe Doc shares your time
zone as well. I don't know a better soltuion aside from email tag though.
Anyone have any ideas?