It looks like Goswin's been working on a similar approach: ia32-libs-tools.
See http://lists.gag.com/pipermail/debian-ia32-libs/2008-February/000362.html I'll add some comments comparing both techniques. My idea was to make some kind of extra section/branch/whatever in a repository. For example, in my local repository I build amd64 packages from downloaded i386 ones. A multiarch repository (ftp.debian.org) would use packages from the local filesystem. There's no need to create source packages therefore. Another topic's the maintainer's involvement. I think they should be left out. It's difficult enough to maintain a package, more if they must consider multiarch support and specially if they don't have access to the arch in question. When using several packages (instead of ia32-libs) the problem is reduced to dealing with dependencies, many of them easily automated. This could be handled by ia32-libs maintainers. Of course, the package maintainer may know the best (multiarch) dependency relationships. The overall point is to be as unobstructive as possible. The only changes would be in i386-only applications, that would use alternative development libraries. Goswin's using the ia32- prefix while I use the -i386 suffix (as in libc6-i386). The latter's been helpful during development (version/section/naming comparisons). In my scheme, dependencies on native packages are only made when file conflicts would occur. This happens a lot in development libraries. The goal again is to be less obstructive. Besides, 32-bit libraries should be able to be installed independently; they run independently. Regarding my scripts, they aren't as efficient as I'd like but they get their job done. I could deploy the repository right now if I had the bandwidth (and signed the files). Supporting the applications I mentioned before means ~29MB, 146 packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
