Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog

[Alexis Ballier]

On Wed, 27 Feb 2013 20:05:58 +0100
hasufell <hasufell@g.o> wrote:

> This is just my own view on this and NOT complete, Tommy[D] will
> probably have a more complete list what the eclasses currently lack
> and where they will fail.
> Mgorny will have a more complete list why multilib-portage is a bad
> hack.
>
>
> PM level:
> pro:
>   - one-blow solution, tree-wide
>   - _much_ less modification on ebuilds needed
>   - will be properly documented in the spec, something people can
>     rely on
>   - multilib-portage has years of experience on ABI issues
> con:
>   - difficult to maintain (please count the number of people who
>     understand portage code)
>   - slower fixes
>   - still no merge into mainline in sight, could very well take
> another few months, if at all

- suboptimal (run all the src_* phases twice)
- from what i've understood it does not deal with nolib packages
  properly: what happens for eg coreutils or texlive-latexextra ? Do we
  unpack, build and install them twice ? Really ? Try to install
  tl-latexextra on a 5400rpm laptop disk, you'll see you do not want
  that time to double :)
- the spec will likely include specificities: e.g.
  setting PKG_CONFIG_PATH
  what happens if I want a multilib ocaml install (stupid idea btw but
  that's an example): the pkgconfig equivalent for ocaml is findlib.
  You will likely want to override OCAMLFIND_CONF for doing a multilib
  install. You will need to change the spec.

> eclass level:
> pro:
>   - easier to maintain (eclasses are generally easy understandable)
>   - quicker to fix and to extend
>   - solution is NOW available
> con:
>   - more likely to break stuff as all eclass based solutions, because
>     there are no eclass-APIs and no spec

if done correctly this should not happen, but that's true the eapi
barrier is not there.

>   - needs much more modification on ebuilds, especially for weird
> build systems

the eclass you proposed implements more or less the multilib-portage
solution without much changes. if you want to do it cleanly (out of
source build, etc) then yes you need much more changes but also get
something you cannot do from the PM side.

>   - not tree-wide, slow per-package migration

it is a pro rather than a con for me: do we really want lib32 to be the
32bits copy of lib64? or do we want here only what actually makes
sense, on a per-package and per-need basis? (see also the tl-latexextra
example above)

Alexis.