On Tue, 1 Nov 2016 14:16:18 +0100 Michał Górny <[email protected]> wrote:
> On Tue, 1 Nov 2016 09:29:09 +0000 > Sergei Trofimovich <[email protected]> wrote: > > > > 4. What are the common tasks that you find unnecessarily complex / > > > lengthy with the current version specifications? > > > > Problem 1: > > > > Sometimes upstream decides that one of their dependencies > > is broken on a version range (package compiles but does > > horrible things due to accidental semantic change in a dependency) > > > > Common example is aeson. Upstream dependency looks like: > > || ( ( >=aeson-0.5 <aeson-0.10 ) > > ( >=aeson-0.11 <aeson-1.2 ) ) > > So version ranges with exclusions. How many versions usually need to be > excluded? Is this usually limited to a few versions? Are the versions > very specific or would you need to restrict them e.g. 0.10*? Usually the exclusions is a single range of 2 unpredictables versions: [when_broke .. when_fixed) and usually they can't be easily covered by '*' wildcard. https://hackage.haskell.org/package/Agda-2.5.1.1 is a good example: hashtables (>=1.0.1.8 && <1.2 || >=1.2.0.2 && <1.3) # removes >=1.2 ... <1.2.0.2, today expands as: 1.2.0.0, 1.2.0.1 mtl (>=2.1.1 && <=2.1.3.1 || >=2.2.1 && <2.3) # removes >2.1.3.1 ... <2.2.1, today expands as: 2.2, 2.2.0.1 transformers (==0.3.* || >=0.4.1.0 && <0.6) # removes >=0.4.0.0 <0.4.1.0, today expands as: 0.4.0.0 > > Problem 2: > > > > Haskell ABI it a SUM of: > > - ABIs of its dependency libraries > > - own exports > > Library version is a part of that library ABI. > > Thus library ABI is guaranteed to change every library release. > > > > It means that once end user merges a library version bump > > user needs to rebuild all library's transitive reverse dependencies. > > Sometimes library is deep in the dependency chain (5-10 levels deep). > > > > There is no way to express that style of dependency in portage: > > https://bugs.gentoo.org/show_bug.cgi?id=449094 > > and app-admin/haskell-updater is still a needed thing to restore > > world sanity after a library upgrade. > > Just to be clear, I was asking purely about versions and not > slots/subslots and other magic like that. Fair. > However, while at it I should > point out that the spec doesn't really cover pure-DEPEND :=, so there > is no guarantee that Haskell := operators will work at all. Yeah. It settled mostly because DEPEND="$RDEPEND + foo" is idiomatic at least in non ':=' world and no tools complained about ':=' in DEPEND. This slight deviation in DEPEND/RDEPEND representation of the same intent, say: aeson (>= 0.10 && < 1.2) would have to be solved with something from the list: 1. use some cheap sed-like bash hack to strip away ':=' from RDEPEND when assigning it to DEPEND: RDEPEND=">=aeson-0.10:= <aeson-1.2:=" DEPEND="${RDEPEND//:=}" A bit fragile but might be good enough. 2. raw data duplication in ebuilds. DEPEND=">=aeson-0.10 <aeson-1.2" RDEPEND=">=aeson-0.10:= <aeson-1.2:=" makes ebuilds less editable as you need to update the same version changes in 2 places instead of one once you port a thing to aeson-1.2 and beyond. 3. have another layer of bash to generate DEPEND/RDEPEND contexts: # in ebuild add_haskell_run_build_depends 'aeson (>= 0.10 && < 1.2)' # somewhere in haskell-cabal.eclass: add_haskell_run_build_depends() { DEPEND+=$(depend_magic "$@") RDEPEND+=$(rdepend_magic "$@") } 4. <else?> Is it worth it? Maybe. Glancing at a popular example $ git grep 'dev-libs/openssl:0[= ]' seems there is no ebuilds that mention both ':0=' and ':0' style depend at the same time. If Gentoo is planning to steal ':=' DEPEND syntax in future tools and docs should be improved to detect/avoid misuse sooner than later. -- Sergei
pgp_R5vAUNpkN.pgp
Description: Цифровая подпись OpenPGP
