On Tue, 1 Nov 2016 14:16:18 +0100
Michał Górny <mgo...@gentoo.org> wrote:

> On Tue, 1 Nov 2016 09:29:09 +0000
> Sergei Trofimovich <sly...@gentoo.org> 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

Attachment: pgp_R5vAUNpkN.pgp
Description: Цифровая подпись OpenPGP

Reply via email to