On 07/20/2011 07:42 AM, Richard Purdie wrote:
On Wed, 2011-07-20 at 16:26 +0200, Frans Meulenbroeks wrote
there is already patch sent to fix it.
http://patches.openembedded.org/patch/7933/
libiconv is not default provider of virtual/libiconv on
eglibc/glibc based systems and sometimes that can trip you
over. It happens and as long as we find it and fix it quickly
I don't see a problem. Do you ?
Some people seem to think differently about this. I still recall the
pile of shit Koen dumped upon me about a year ago when I accidentally
removed a version of openssh or so that was still used. Even though
the problem was fixed very quickly after it was brought to my
attention. Ah well. As Orwell already said "all animals are equal but
some animals are more equal than others".
IMO we should not get so pedantic that people start getting
scared of making changes
It was by no means my intention to be pedantic.
Then again I *do* think it is good practice if someone creates a new
recipe that (s)he tests it before submitting it.
And my impression was that one of the goals of YP and oe-core was to
increase the quality level.
One of the ways to increase quality is to do a build after pulling
changes and before committing them.
(at least I feel that is one of the ways to increase quality, and yes
there are other ways too).
And where people work, mistakes happen. One can accept that, but one
can also see if there are ways to improve and avoid that a problem
re-occurs.
I think its fair to ask how this happened and it appears to be due to
PREFERRED_VERSION and/or PROVIDER confusion. Its unfortunate but I think
the people involved will not do it again :).
Yes, the lesson has been learned, I am working on adding a UCLIBC build
into the mix, and the Autobuilder will have a vanilla oe-core build with
both uclibc and egligc some time soon as well.
Please chalk this up to live and learn not a common practice.
Sau!
I don't think its entirely fair to immediately bring into question the
overall quality goals as we are continuing to work towards those and
this is an exception, not the norm.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
