> > I don't think so. I see at least a few possible uses for this : > > > > 1) have a shared filesystem between machines of multiple architectures > > 2) test your programs on architectures you don't have by using qemu > > It might have its use there but it can't be simply done. The files > from two packages must be disjunct. That was my point. Moving binaries > into subdirs and calling them by their arch (e.g. /bin/ls/i486) would > solve that. But something has to do this change. Either the packaging > itself or dpkg when unpacking the deb. Both would mean a major change > in what we (and everybody else) currently have. > That could just be part of the package. Ie. unpacking the files automatically puts them at the right place. > Lets say we do add special dirs for binaries and let dpkg manage > them. How would that work with old and new debs mixed together? Should > dpkg move all binaries into subdirs on upgrade once? Should it move > binaries into subdirs when a second arch gets installed? > It is possible to have both 'normal' and 'directory' binaries at the same time. At least AIX managed to do that, although I don't exactly know how it did that. So this problem is probably non existant. > Also what architecture should be called on x86_64 if both are there? > i486 or amd64? Should that be configurable? > What do you mean here ? > I imagine that would need kernel support to work for "#!/bin/sh" and > the like which again raises the question of compatibility. > > No. #!/bin/sh would just execute /bin/sh as usual. > Weigh the gain against the work and hopefully you will see that the > cost outweigh the gain by a lot. If you want to share a filesystem to > i486 and amd64 systems I guess you could use a unionfs for amd64 that > has i486 as base and then just adds the 64bit stuff. Thats probably > far simpler and better than adding the complexity to dpkg. > Well no. Because there is far more use then i486 and amd64. I don't think dpkg needs extra changes beyond being able to install packages for another architecture and doing the dependencies per architecture (which all is necessary for multiarch anyway). L & L p2. -- goa is a state of mind
Attachment:
signature.asc
Description: Digital signature