On Fri, Nov 30, 2012 at 11:49:59AM +0000, Adam Spiers wrote: > Good to know! Do you know if they have switched to any of the new 2.x > releases I made in the last year?
They're both still on stow 1.3.3, since that's what Debian stable currently ships. I'd expect them to upgrade when Debian does. GARStow uses the latest stable stow, which appears to work happily enough. The only ongoing problem is that it's a bit awkward upgrading either Perl or stow when both are stowed. (I've currently got a wrapper that does the appropriate magic with $PERLLIB, etc., so it can run perl/stow just from the package directories.) > But it is preferable for those with an allergy to symlinks (which > AFAICS tends to be an aesthetic judgement rather than one based on > technical reasons). You do run into the odd package that has technical problems with stow, but they're extremely rare: out of 1955 stowed packages on my build machine, four currently need stow-related patches: - The Python interpreter assumes that it can find the directory containing Python modules by starting from the location of its executable, so it'll end up looking in the stow package directory rather than the target directory, and won't see modules in other packages. (I can't upstream the fix because other tools, e.g. virtualenv, actually rely on this behaviour. Hrmph.) - Qt's qmake tool has some broken symlink-following logic that can't handle two levels of symlinks when looking for its data. - LibreOffice's launch script has a similar problem. - glibc has a configure test that complains if /usr/include/scsi is a symlink (because, on older systems, this meant it was a symlink into the Linux source tree). But if you stow glibc into /usr, then it's correctly a symlink into the glibc package... Thanks, -- Adam Sampson <[email protected]> <http://offog.org/>
