Skip to content

Commit

Permalink
Upgrades 2015-09-06
Browse files Browse the repository at this point in the history 
    cassava
    contravariant
    fclabels
    iproute
    stack
    test-framework-hunit
    yaml

Added dependencies

    ignore
    pcre-heavy
    base-compat
    pcre-light
    string-conversions

Signed-off-by: Magnus Therning <magnus@therning.org>
  • Loading branch information
@magthe
magthe committed Sep 6, 2015
1 parent f156c41 commit c7015a2
Showing 1 changed file with 41 additions and 36 deletions.
Loading

9 comments on commit c7015a2

@PierreR
Copy link

@PierreR PierreR commented on c7015a2 Sep 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a dependency between stack and pcre ?

See this issue : /commercialhaskell/stack#531

But aside from that, stack shouldn't need libpcre. Did you build your stack binary yourself? And, if so, how? There was a brief period when the master version of stack did require it due to the ignore library using it, but now we use a newer version of ignore and set the without-pcre: true for it.

@arch-docker ~ > ldd /usr/bin/stack
    linux-vdso.so.1 (0x00007ffc681b5000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f4e1f69d000)
    libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f4e1f42d000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f4e1f217000)
    librt.so.1 => /usr/lib/librt.so.1 (0x00007f4e1f00f000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f4e1ee0b000)
    libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007f4e1eb79000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f4e1e87b000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f4e1e4d7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4e1f8ba000)

Cheers,

@magthe
Copy link
Contributor Author

@magthe magthe commented on c7015a2 Sep 9, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there is, as you can see here ignore depends on it:

% cblrepo list|grep pcre
highlighting-kate  0.6_1-4 (-pcre-light -executable splitbase)
ignore  0.1.1.0_0-2 (-without-pcre)
pcre-heavy  1.0.0.1_0-2
pcre-light  0.4.0.3_0-1 (-old_base)
regex-pcre  0.94.4_0-77 (splitbase newbase)
regex-pcre-builtin  0.94.4.8.8.35_0-77 (splitbase newbase)

@PierreR
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary ? @borsboom is saying it shouldn't be required because the flag -without-pcre is passed to ignore.

@borsboom
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're building stack using cabal-install, there's no way for stack.cabal to force cabal-install to require the without-pcre flag when building the ignore package (that's something we specify in stack.yaml). Instead, that flag will have to be explicitly set by whatever process is building stack. The haskell-stack and haskell-stack-git packages on AUR use stack itself to build stack, and so they will not require libpcre.

@magthe
Copy link
Contributor Author

@magthe magthe commented on c7015a2 Sep 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PierreR Well, if he says so, but what's the damage? I'm not a stack user so I didn't grasp from the long discussion you linked to what the actual problem was.

@PierreR
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "damage" is that you might end up using stack within docker and it will complain while running in there that it cannot find the dynamic pcre dependencies.

Nothing urgent on my side because I will wait a bit before trying to compile my executable with stack inside a docker anyway. Ultimately this is cool though because a development team can rely on building the same Haskell executable even if they all use a different linux distribution.

@magthe
Copy link
Contributor Author

@magthe magthe commented on c7015a2 Sep 10, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PierreR So, in short, stack puts together a Docker for the purpose of running stack, but it fails at it... hmm... and where is the bug now? ;)

No problems, I'll flip the flag on ignore and keep my fingers crossed we never have any other package depending on it having the flag the other way.

@borsboom
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, in short, stack puts together a Docker for the purpose of running stack, but it fails at it... hmm... and where is the bug now? ;)

@magthe, I totally get what you're saying. We avoid adding system library dependencies for this reason, but unfortunately cabal-install just doesn't give the kind of control necessary to ensure that anyone who does cabal-install stack will get a build the way we intend it. That's one of the things we wrote stack to solve, but of course there's the bootstrapping problem (if you already had stack, you wouldn't need to build stack), and that's why we strive to provide binaries for many platforms.

The docker images actually have libpcre in them, but it looks like it's a different version than your build of stack links with. This bind-mounting of stack's own executable in a container is tricky business and I'm not entirely happy with it. It's especially problematic when the host's platform is significantly different than the guest's (especially with a different operating system where it doesn't work at all, but as we see here it can even be an issue with different Linux distributions). In the the past, we tried "baking" a stack executable into the images, but then there were problems when the host-stack's version was out of sync with guest-stack's. An option we've considered is having the container download a binary that matches the host's version, but that wouldn't play nicely with building unreleased versions from source. Maybe in that case it could do an in-container build of stack from the same commit ID. But none of these options are ideal, and it hasn't become clear yet which direction we should go in. See commercialhaskell/stack#194.

@magthe
Copy link
Contributor Author

@magthe magthe commented on c7015a2 Sep 11, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully this is now fixed with the change that closed #199.

Please sign in to comment.