On Wed, 27 Feb 2013 20:05:58 +0100 hasufell <hasuf...@gentoo.org> 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.
