2010/11/5 Khem Raj <[email protected]>: > On Fri, Nov 5, 2010 at 12:51 AM, Frans Meulenbroeks > <[email protected]> wrote: >> 2010/11/3 Khem Raj <[email protected]>: >>> On Wed, Nov 3, 2010 at 1:21 PM, Frans Meulenbroeks >>> <[email protected]> wrote: >>>> 2010/11/3 Khem Raj <[email protected]>: >>>>> On Wed, Nov 3, 2010 at 12:04 PM, Frans Meulenbroeks >>>>> <[email protected]> wrote: >>>>>> 2010/11/3 Khem Raj <[email protected]>: >>>>>> >>>>>>> >>>>>>> yes a more detailed solution is better. you have to go through the >>>>>>> configure of every >>>>>>> package and understand the behavior then act upon. As I said before >>>>>>> its a tedious task >>>>>>> >>>>>> I'm well aware of this. That is also why in the infrastructure thread >>>>>> I suggested using automated testing to find misbehaving packages. >>>>>> >>>>>> Btw there are 355 .inc files that contain the word autotools and 1899 >>>>>> .bb files. >>>>>> Of course there are lots of dups in there. >>>>>> And maybe for the base recipes we can convince the yocto people that >>>>>> this is a serious QA issue (and they have some people employed to work >>>>>> on this if I understood properly). >>>>>> >>>>> >>>>> numbers means not so much when it comes down to this. I don't know if >>>>> any distribution that even does that >>>>> so I take comfort in everyone being wrong. >>>>> >>>> >>>> I agree that numbers don't mean that much. Just wanted to give an >>>> indication of the possible effort needed. >>>> Also no idea how debian does this. >>> >>> Does it do it in first place ? >> >> I peeked briefly at the sources. >> Debian seems to resolve the problem by going for the max dependencies >> so autotools can pick up everything. >> E.g. for gphoto2, lenny has a depends on both libexif and libreadline >> (see http://packages.debian.org/lenny/gphoto2) >> So basically they go for the max config. >> >> We could do the same. Then again for deeply embedded systems it might >> be desirable to allow more finegrained tuning. >> (did I hear someone say USE flags ? ) >> > > which is good for things that dont care about size. Not so good for > embedded systems I think. > and there are some packages I know which have catch-22 situation so > adding max depends is > also not a wholesome solution. >
Catch22 situations seem mostly to appear because one packag exports both a lib and a (sample) program. One example that I saw recently was libcdio and libcddb. Probably the only other way of catch 22 situations are triple or quadruple staged builds.(build A, build B rebuild A maybe rebuild B) Frans _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
