Fix build with persistent-2.10.
Added an additional constraint that persistent needs. This also builds with persistent-2.9.2 without needing any cpp.
This commit is contained in:
parent
d0d416b215
commit
904b175707
4 changed files with 43 additions and 6 deletions
|
@ -11,6 +11,7 @@ git-annex (7.20191011) UNRELEASED; urgency=medium
|
|||
when they become empty, further reducing the size of the git-annex branch.
|
||||
* OSX: Deal with symbolic link problem that caused git to not be included in
|
||||
the git-annex.dmg.
|
||||
* Fix build with persistent-2.10.
|
||||
|
||||
-- Joey Hess <id@joeyh.name> Thu, 19 Sep 2019 11:11:19 -0400
|
||||
|
||||
|
|
|
@ -244,10 +244,15 @@ runSqliteRobustly tablename db a = do
|
|||
|
||||
-- Like withSqlConn, but more robust.
|
||||
withSqlConnRobustly
|
||||
:: (MonadUnliftIO m, MonadLogger m, IsPersistBackend backend, BaseBackend backend ~ SqlBackend)
|
||||
=> (LogFunc -> IO backend)
|
||||
-> (backend -> m a)
|
||||
-> m a
|
||||
:: (MonadUnliftIO m
|
||||
, MonadLogger m
|
||||
, IsPersistBackend backend
|
||||
, BaseBackend backend ~ SqlBackend
|
||||
, BackendCompatible SqlBackend backend
|
||||
)
|
||||
=> (LogFunc -> IO backend)
|
||||
-> (backend -> m a)
|
||||
-> m a
|
||||
withSqlConnRobustly open f = do
|
||||
logFunc <- askLogFunc
|
||||
withRunInIO $ \run -> bracket
|
||||
|
@ -258,8 +263,11 @@ withSqlConnRobustly open f = do
|
|||
-- Sqlite can throw ErrorBusy while closing a database; this catches
|
||||
-- the exception and retries.
|
||||
closeRobustly
|
||||
:: (IsPersistBackend backend, BaseBackend backend ~ SqlBackend)
|
||||
=> backend
|
||||
:: (IsPersistBackend backend
|
||||
, BaseBackend backend ~ SqlBackend
|
||||
, BackendCompatible SqlBackend backend
|
||||
)
|
||||
=> backend
|
||||
-> IO ()
|
||||
closeRobustly conn = go maxretries briefdelay
|
||||
where
|
||||
|
|
|
@ -71,3 +71,5 @@ The Glorious Glasgow Haskell Compilation System, version 8.6.5
|
|||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
|
||||
git-annex has been awesome for managing a massive collection of raw images and video clips across several storage targets and editing systems.
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,26 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2019-10-17T15:04:29Z"
|
||||
content="""
|
||||
Thank you for maintaining the homebrew build, and for tracking down the
|
||||
persistent version.
|
||||
|
||||
I've fixed this now, and will be making a new git-annex release today.
|
||||
|
||||
FWIW, git-annex.cabal intentionally doesn't pin higher bounds of library
|
||||
versions. My thinking is that people who want a build pinned at known
|
||||
working versions should use stack to build, while people who are building
|
||||
with cabal tend to be the kind of people who are integrating git-annex with
|
||||
a larger system, and will probably want to build with whatever library
|
||||
versions shipped with their system (eg in a linux distribution), or
|
||||
with the latest and greatest.
|
||||
|
||||
That does mean that everyone building with cabal is likely to run into this
|
||||
kind of breakage now and then, rather than me not noticing it until I update
|
||||
the pinned versions. Kind of offloading a bit of the work from me onto users,
|
||||
I have to admit.
|
||||
|
||||
You can of course patch git-annex.cabal to use an older version if
|
||||
necessary.
|
||||
"""]]
|
Loading…
Reference in a new issue