Date: Wed, 21 Mar 2007 05:27:49 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit/i386 ports/packges on amd64 Message-ID: <20070320182749.GG76696@turion.vk2pj.dyndns.org> In-Reply-To: <45FFB0D3.8030201@icyb.net.ua> References: <45FE7615.3090606@icyb.net.ua> <ab581e310703190929x269bc9a3w364f801fbeff8b0e@mail.gmail.com> <346a80220703191135w3e4fdb92ic8c93a38ff37f15a@mail.gmail.com> <45FFB0D3.8030201@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Mar-20 12:00:51 +0200, Andriy Gapon <avg@icyb.net.ua> wrote: >Well the problem with this approach is that you can't have both amd64 >and i386 versions of the same package installed. >At least a few problems here are as follows: >1. package name doesn't include platform, so packages conflict even on >pkgdb level >2. files are installed into the same locations >3. properly tracking dependencies is also not possible because of #1 >4. even if all i386 and all amd64 packages are unrelated then there >still can be problems because of i386 shared libraries being installed >into 64-bit "lib" directories and thus not visible to run-time linker. The solution to all these problems is to have two different sets of hierarchies. The easiest would be /var/db/pkg32, /usr/X11R632 and /usr/local32 (and maybe /var/db/ports32). This means that the hierarchy within the ports/packages doesn't change, just the base directory. The location choice would need to be controlled by a flag (eg '-32') on the pkg* tools since there's easy way to distinguish between different architectures within packages. (Packages get unpacked into temporary directories so maybe an architecture flag within +CONTENTS would be useful, though some packages are architecture independent). >There is another problem with arch specification in ports: currently >i386-only is used to mean several different things - (1) software indeed >makes sense only on i386 platform; (2) software is actually a thirdparty >i386 binary; (3) software is not 64-bit clean. Is this such a problem? An amd64 in 32-bit mode looks mostly like an i386 so there any need to distiguish these sub-classes. >As Peter Jeremy already mentioned 32-bit Java is not running on amd64, >even in such a chroot-ed environment. For me it either crashes or hangs. I didn't mention it but the way forward for this is for someone interested to develop small test cases that don't work so the underlying cause can be tracked down. Java is such a big app that just saying it doesn't work isn't helpful. OTOH, a 50 line test program that doesn't work would be manageable. --=20 Peter Jeremy --+g7M9IMkV8truYOl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGACel/opHv/APuIcRAk+CAJ4ymaxWh36tPj2MwR2he8kl9Vu5QwCfVMlc NYE13pfqZKh/t3LomxoLS3M= =QvCU -----END PGP SIGNATURE----- --+g7M9IMkV8truYOl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070320182749.GG76696>