[oiac-discuss] OpenIndiana Addon Consolidations

[Adriaan de Groot]

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.")


>   - 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.

[ade]