"Andy Wang" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 23 Apr 2008 19:39:32 -0500:
> Just wanted to follow up on this e-mail from a while ago. Any new > progress on creating documentation for how gentoo builds it's > emul-linux-x86-* files?<br><br>Thanks,<br>Andy<br><br><br><div > class="gmail_quote">On Mon, Nov 26, 2007 at 3:52 PM, Andy Wang <<a > href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>> wrote:<br> > <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, > 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div > class="Ih2E3d">On Nov 23, 2007 12:10 PM, Mike Doty <<a > href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>> wrote:<br> If you'd kill the HTML next time, some of us would be grateful. Not everyone here likes webmail, and HTML based messages can be a security issue, so some of us choose not to enable it or use clients that handle it. Thanks. I don't have a direct answer to your question, but FWIW if I were doing it... I'd use the 32-bit chroot (or build on a 32-bit machine) and use FEATURES=buildpkg so all the packages ended up as tbz2 binaries. For individual cases that should be enough on the build side. On the binary package consumer, I'd use a 32-bit chroot again (to keep the 32- bit packages tracked separately from the 64-bit ones) and either emerge a more or less full system or use package.provided and/or --nodeps when merging individual packages if I chose not to do the full 32-bit system. For something more suitable for general distribution, IOW, usable directly from the main system's portage/other-pm, I'd use the binaries created in the first step as the "sources", and build an ebuild script wrapper around them to untar and install them manually (and to an appropriately different location for libs, or name for executables, than the 64-bit stuff), while tracking them using emul- (or similar) to keep them separate from the 64-bit packages of the otherwise same name. The same skeleton untar and install script could be used for all such packages, with specific extra configuration, etc. attached as necessary. That seems fairly straightforward and would the existing portage binary package capabilities, but is obviously not quite the method they took, as they have more generalized packages that include binaries (libraries, etc) from multiple normal packages. The advantage of doing it as above, however, would be that the generic wrapper ebuild script could be simply renamed as appropriate to use with 32-bit packages other than those currently supplied. As I said, FWIW... It may or may not be suitable for your purposes. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
