Lennart Sorensen: > I would think it was much better to just install the 64bit and then > install a 32bit in a chroot. That keeps both available at the same time > (since a 64bit kernel will run both).
That's the very alternative. I'll have to read up this list a little further to see how much effort it is. > Sharing /home sounds perfectly reasonable. Of course if the use has any > binaries compiled for 64bit they won't run with a 32bit kernel, and > 32bit programs may require libraries that aren't on a 64bit system. ok, but that should not affect a shared /home anyway (as long as i don't use a ~/bin or something - i use to install additional stuff in /usr/local/bin or in /opt) > > /var/cache/apt/archives ... i can't see any problem here, can you ? > > Not sure. Of course anyone that does an apt-get clean after an upgrade, > won't have anything in there anyhow. My usual configuration is to delete 'obsolete' debs and x64 and x32 should have different package names. Actually, i don't know...do they ? > > /usr/share .... a relatively huge peice - but will apt refuse to manage > > (mainly, to deinstall) stuff that was updated by the 'other debian' ? > > (Would at least /usr/share/doc be safe ?) > > I don't think dpkg will like that idea at all. and i'm not sure if i like to dare the experiment ;) because by any logic, you should be right here. > > /usr/scr .... i will have several source trees from kernel.org or > > debian, and i've no problem with backups of different .configs, so > > basically this should work...? > > Your sources you can do whatever you want. Since dpkg does install some > things to /usr/src, it is not a good place to keep your own sources. I keep different kernel.org and debian trees in /usr/src since years, and i'm working as root more times than as user since years, anyway, i think i am careful. (And i'll not forget that funny accdident when i moved /bin into some unknown location deep in the hierarchy :) They have different naming (linux and lkinux-source), and i use the kernel compile-in-version feature, and i don't need make-kpkg at all. I work with some generic symlinks in /boot and i use to boil down any tedious commandline into a scripted single command, like switching kernels by modifying the links, or the whole procedure from compiling til final setup, so usually don't need to change grub menu.lst. Using make-kpkg for custom compiling creates at least the same amount of RTFM and maintenance as the kernel.org way, maybe even less... it's a good tool for debian packages, and automated image update, of course. > I don't know if the swap format is identical between architectures. You > would have to find that out first. ok. > > I discarded the idea to share /tmp, don't want to fix the size. > > I also think i will use tmpfs. > > /tmp is often better done as tmpfs in ram anyhow. The idea is to mount /tmp as tmpfs, and i can't think of any problem right now. Usually it's only a few M used by desktop sessions. I'll look closely at chroot next, but will at least keep some free space for now, for going parallel-boot later. thx for input -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
