I'm a little surprised that a veteran Debian user would fall into this kind of trap (again :). I think guix looks very interesting, but a couple of tips if "all" you need is to "code on the edge" in Debian:
1) Run Debian stable. Possibly add stuff from backports if you need to (eg: newer kernel for drivers. Newer xorg. Hopefully this shouldn't ever be needed for mainstream workstations - modulus closed source graphics drivers).
2) Don't mix'n'match [packages from testing/unstable with stable]. Don't pin. Just do not do it. [Don't run testing/unstable... unless you are testing testing].
3) For utilities not in stable - some can go in ~/opt/{bin,lib,man} -- living in ~/opt/xstow/$package-$version/ -- see "man xstow/apt-get install xstow" -- and set your path, ld-path, man-path ("man man") and friends to point to ~/opt/man etc.
I also have a ~/opt/venv/util/bin in my path so I can go "pip install mercurial" without worrying about system python packages etc. If you go down this path be aware of "apt-get build-dep mercurial|python-$foo" as a reasonably sane way to get system dev headers for c libraries things you pip install in your venv(s).
Think of the venvs as disposable! Might have to trash them on a dist-upgrade and recreate. Ditto for ~/xstow.
But none of that is much better than the mess Wingo found himself in, therefore:
4) Embrace the glorious trinity formed by lvm, schroot and debootstrap! With lvm-backed schroots you can have a source-chroot for each of testing, sid/unstable and experimental. Complete with rollback, named snapshots and automagic binding of $home (with among other obvious benefits - your x session cookie).
Schroot documentation/wiki/howto do need a facelift, though.
[Note that auto-bind-mounting home can now be set in schroot.conf IIRC -- see man schroot]
PS: If you have $home on nfs and mount it on both 32bit/64bit linux as well as Solaris... you can put stuff in ~/opt/$arch/.. and dance around in .xsession and/or .bashrc... but I don't recommend it unless you have to...
1) Run Debian stable. Possibly add stuff from backports if you need to (eg: newer kernel for drivers. Newer xorg. Hopefully this shouldn't ever be needed for mainstream workstations - modulus closed source graphics drivers).
2) Don't mix'n'match [packages from testing/unstable with stable]. Don't pin. Just do not do it. [Don't run testing/unstable... unless you are testing testing].
3) For utilities not in stable - some can go in ~/opt/{bin,lib,man} -- living in ~/opt/xstow/$package-$version/ -- see "man xstow/apt-get install xstow" -- and set your path, ld-path, man-path ("man man") and friends to point to ~/opt/man etc.
I also have a ~/opt/venv/util/bin in my path so I can go "pip install mercurial" without worrying about system python packages etc. If you go down this path be aware of "apt-get build-dep mercurial|python-$foo" as a reasonably sane way to get system dev headers for c libraries things you pip install in your venv(s).
Think of the venvs as disposable! Might have to trash them on a dist-upgrade and recreate. Ditto for ~/xstow.
But none of that is much better than the mess Wingo found himself in, therefore:
4) Embrace the glorious trinity formed by lvm, schroot and debootstrap! With lvm-backed schroots you can have a source-chroot for each of testing, sid/unstable and experimental. Complete with rollback, named snapshots and automagic binding of $home (with among other obvious benefits - your x session cookie).
Schroot documentation/wiki/howto do need a facelift, though.
See also:
https://www.pseudorandom.co.uk/2007/sbuild/
https://wiki.debian.org/Schroot/e
https://wiki.debian.org/CrossCompiling
[Note that auto-bind-mounting home can now be set in schroot.conf IIRC -- see man schroot]
PS: If you have $home on nfs and mount it on both 32bit/64bit linux as well as Solaris... you can put stuff in ~/opt/$arch/.. and dance around in .xsession and/or .bashrc... but I don't recommend it unless you have to...