[oiac-discuss] OpenIndiana Addon Consolidations

[Guido Berhoerster]

* Adriaan de Groot <groot at kde.org> [2010-11-24 13:46]:
> On Sunday, November 14, 2010 05:35:21 pm Moinak Ghosh wrote:
> > * We also would in some cases build packages from source.
> >   These would include:
> >   - C++ packages where BeleniX aims to use a FOSS compiler
> >     like Gcc (maybe LLVM, Clang in future). This includes KDE.
> 
> As far as KDE goes, we'd like to see an "upstream" model like the following 
> (beware, ASCII art)
> 
> 
> KDE.org --> KDE4-OSOL +-> Belenix --> OI
>                       +---------------^
> 
> e.g. KDE releases go through the KDE4-OpenSolaris (seriously, we need a 
> rename) project for initial packaging. This yields specfiles - and depending 
> on how well we work together these may be instantly (re-)usable in Belenix - 
> which can be used to build packages. KDE4-OSOL delivers straight-up KDE4 with 
> Studio while Belenix delivers a further polished and tuned user experience 
> with gcc; Belenix improvements then flow back up the chain upstream to 
> KDE.org. (Which is just a longer way of me saying "What Moinak said.")

I also think that this is a very sensible approach to make
optimum use of our rather scarce resources.

> >   - In addition we also feel it is important to pursue general
> >     usage of a FOSS compiler/toolchain as opposed a non-free
> >     one in the long run - this is a future goal.
> 
> I do occasionally worry about the long-term availability of Studio for Free 
> Software projects. I don't think we touch any of the redistributables from 
> Studio 12 -- we used to (re-)package them in a way that looks to be 
> incompatible with the current Distribution Readme. The software entitlement is 
> breathtaking in its clarity, though:
> 
> http://developers.sun.com/sunstudio/documentation/ss12/sun_studio12_entitlement.txt
> 
> 
> > > There is a draft proposal outlining rules and procedures for the
> > > OIAC at:
> > > http://wiki.openindiana.org/oi/OpenIndiana+Addon+Consolidations
> > 
> >    We have gone through this and are generally happy with the
> >    proposals.
> 
> Same here, although we'd need to put some effort into making our stuff fully 
> compliant with the naming conventions.
> 
> 
> > 
> > > * A solution for dealing with different C++ ABIs (gcc vs.
> > >  SunStudio and stlport vs. stdcxx), currently being discussed
> > >  within SFE as well
> > > * The need for an initial set of macros (possibly improved
> > >  readability, avoidance of boilerplate code, more RPM-like to
> > >  accommodate Belenix?)
> > 
> 
> Perhaps something needs to be said about C++ STLs still, since we *do* build a 
> number of duplicate packages with stdcxx4 while JDS still uses Cstd. We could 
> name things <foo>-cstd and <foo>-stdcxx4, but I don't know how to get them to 
> co-exist.

A possible solution recently discussed at SFE was to separate
different ABIs through the filesystem, thus having Studio
stlport4 compiled libraries under /usr/lib since this is what JDS
uses, Studio stcxx under /usr/stcxx/lib, and putting GCC compiled
libs under /usr/gcc/lib or /usr/g++/lib.
The most important thing is that we can agree on a common
solution across broject boundaries.

-- 
Guido Berhoerster