[oiac-discuss] OpenIndiana Addon Consolidations

[Moinak Ghosh]

Hello,

   We have spent spent some time discussing this amongst
ourselves and on belenix-discuss about the plans for BeleniX
ahead.

We have come up with the following approach which we feel
would best allow us to participate, leverage and contribute
within the OpenIndiana (and Illumos) community.

* The BeleniX team would work with and be part of the overall
  OpenIndiana community in testing, contributing and maintaining
  spec files and patches.

* BeleniX would make use of OpenIndiana IPS packages and
  import these as RPMs to be binary compatible.

* 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.
  - In certain cases we may add additional tweaks and patches.
    Eventually however, for non-C++ pieces we will work to get
    these back into OpenIndiana and also into the actual upstream
    projects.
  - This means that we will have BeleniX spec files only where
    necessary.
  - 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.

* We intend to keep the same package namespace and boundaries
  as OpenIndiana - this follows from the above approach of importing
  binary packages.

* We intend to work with the KDE-Solaris team to push KDE patches
  upstream.

Please see inline for more ...

On Thu, Nov 11, 2010 at 3:45 PM, Guido Berhoerster <gber at openindiana.org> wrote:
>
> Hello, fellow software porters!
>
> In order to get everyone up to date, and to start a dialogue with
> the members of third-party packaging projects about
> collaboration, we will provide a rough outline of the planned
> project.
>
> The OpenIndiana Addon Consolidations (OIAC) are primarily an
> effort to provide OpenIndiana users additional high quality
> software packages which are optimally integrated with the rest of
> the system. For OpenIndiana (and probably also Belenix)there is,
> for example, a demand for alternative desktops such as KDE and
> XFCE, so turning these into well integrated alternatives to the
> GNOME desktop would fall under this goal. Furthermore, it would
> be desirable to cooperate with other Solaris packaging and
> distribution communities where possible in order to avoid wasting
> scarce resources by duplicating work.
>
> Cooperation could, in our opinion, take different forms; one of
> them would be complete integration, where development takes place
> within the OI project.  Another possibility would be to consider
> such projects as "upstream" for OI where rapid development
> continues to take place and contributors from the upstream
> project itself or from OI import known stable or tagged versions
> of packages at regular intervals, adapt them to the OI packaging
> standards and rebrand them.  They would then also be responsible
> to feedback, enhancements, and bug reports to an upstream project
> and collaboration could e.g. be additionally facilitated by the
> use of a common bugtracker.  Projects which operate "upstream"
> from OpenIndiana (e.g. Belenix) could handle this similarly.

   Yes.

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

> It is primarily derived from the OpenSolaris contrib and Fedora
> development processes and incorporates a few ideas from members
> of the OpenIndiana community, please note that this is not set in
> stone but rather intended as a basis for discussion here. There
> are a number of yet unsolved but important issues, namely:
>
> * 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?)
>

   For the C++ ABI one option is to use pathnames to separate
   C++ libraries based on compiler to avoid confusion and conflict.
   For eg. /usr/lib/gcc/ and /lib/gcc/ for g++ built stuff. /usr/lib and /lib
   remains studio built by default.

Regards,
Moinak.
-- 
================================
http://www.belenix.org/
http://moinakg.wordpress.com/