On Wed, Dec 22, 2010 at 4:12 PM, Luke Kenneth Casson Leighton <[email protected]> wrote: >> (Basically, that adds Build-Recommends, in addition to Build-Depends.) >> >> As an example, take bash: >> Package: bash >> Binary: bash, bash-static, bash-builtins, bash-doc, bashdb >> Build-Depends: autoconf, autotools-dev, patch, bison, libncurses5-dev >> [!bootstrap], texinfo [!bootstrap], debhelper (>= 5), texi2html >> [!bootstrap], locales, gettext, sharutils, time, xz-utils >> Build-Depends-Indep: texlive-latex-base [!bootstrap], ghostscript >> [!bootstrap] >> >> This has the advantage that it doesn't require duplicating source >> packages, and the changes required to an package are not that >> difficult usually. > > ... it's somewhat intrusive, and, i think you'll find that actually > there are cases where those packages _are_ required, but that you can > get away with "native" versions of the same. and, also, i think > you'll find that it's a bit more than just adding a [!bootstrap] flag, > but that compilation options are also required (configure > --without-texinfo for example - bit of a fake example but you get the > idea)
clarification: "native" in OE terminology means "a package that's installed on the host, NOT the target". so, "python-native" would actually run on the host system. the number of cases where "-native" packages are required for cross-compiling is actually quite high. this is simply unavoidable and has absolutely nothing to do with OE (or any other tool utilised). basically, you just have to get used to the fact that, whatever you do, package changes are going to be required. exactly how those changes are expressed, conveniently, i do not know - and would very much prefer that someone _else_ comes up with ideas. l. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
