Re: Introducing GNU Guix

[Adam Spiers]

On Fri, Nov 30, 2012 at 12:19 PM, Adam Sampson <address@hidden> 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.