On Fri, Nov 30, 2012 at 12:19 PM, Adam Sampson <[email protected]> wrote: > 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.
Right. 2.2.0 is in Debian testing, so it will happen. > 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.) PERL5LIB handling has changed in 2.x; I'm not sure off-hand how that would affect the above. >> 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 for the info! It would be nice to get fixes/workarounds for these upstream, or at least document them in Stow.
