[oi-dev] Studio/GCC c++ libraries and OI future :)

[Nikola M.]

On 10/ 9/13 08:10 PM, Alexander Pyhalov wrote:
> So, we have two loosely related issues to discuss.
>
> On 10/09/2013 21:34, Thomas Wagner wrote:
>
>>> When we can rebuild
>>>   everything with GCC, I think it's a good idea to rename libraries to
>>>   original names and move back to /usr.
>>
>> Yes, true for the very limited world of a g++ only Distro. You loose
>> binary compatibility for all 3rd party software which expects Studio
>> compiled C++ libraries in /usr/lib.
>> I do not remember that this has been discussed, but I may have missed
>> that.
>>
>> To avoid such future incompatiblities one should really discuss in
>> depth if even with a purely gcc/g++ compiled complete distro that
>> the g++ libs still go into /usr/g++.
>> You gain the advantage to still deliver for special cases Studio
>> compiled C++ libs into /usr/lib and keep that binary compatibility.
>
> I think that without unlimited access to Studio compiler, without 
> ability to fix its bugs we can't really support studio-compiled disto, 
> it's a dead end. Moving some of the libraries to /usr/g++ creates a 
> mess (you should instruct software to look for this library here, and 
> for this one there, and so on...). I think it would be the honest goal 
> to drop Studio support and to make the whole distribution buildable by 
> GCC.
Yes, It was more then obvious even in opensolaris days, that depending 
on closed compiler, can not make project survive and be independent, and 
that is absolutely true, at least for the illumos distributions.
Uneducated question: Could rest of the system work if just illumos is 
built with Studio? (I think illumos could still be built with studio?)

I think that executing older binaries could be made by making branded 
zone with libraries available thus far (or in some of recent OI /dev 
releases, par example a7 and we should already have s10 branded zone) 
and that could be sort of solution for binary compatibility with 
software compiled with studio, closed or open.
(Q: Could such apps from Zone use X server to display graphics? )
That way we wouldn't loose all those OI 'customers' that depend on all 
that proprietary software for Solaris, for which that found save haeven 
in OI till now (people already complain that that not running older 
Solaris binaries would kill their usage case with OI)

It could be also discussed and contributed to upstream projects that 
make binaries available and work on OI, to support new OI changes in the 
next releases/contrubute changes to them.
(first of many Virtualbox and then to se we have ready build of Apache 
OpenOffice for new OI etc)

Also, Studio should be able to install and run on OI, in case people 
want to compile their projects and software with Studio too,
but that would also require for Oracle to support new changes in OI as a 
new platform,
not only as Opensolaris/Solaris, but as OI itself. (and I don't know if 
Oracle would want to support OI with Studio, that might be very good for 
them in terms of porting software, but don't know)

Or Studio could be running inside that a7 branded-zone for now, with 
adjustments in building to new OI state of affair.

But beside making that compatibility branded zone, and effort on 
supporting 'old' state of libraries,
OI surely should *not* be stopped in it's advancements by old libraries. 
And OI must be able to do sort of make-world. (with consolidations or 
withoout)
Just we need to understand, that it is actuall kiss-goodbye to any 
binary compatibility of applications for Solaris and OI in the future.

>
> 2a) moving away from legacy consolidations to single build system, so 
> that every part can be modified without headache

We should be thinking about: why consolidations are there in the first 
place?
My understanding was that they were introduced, to make 
inter-dependencies inside
distribution sub-projects locked into version and not to interfere with 
other cosolidation or stand alone software (several dislocated teams 
through all over the world that build and test separate consolidations)
and to make life of separate teams making separate consolidations easier 
and allow separate version control of consolidations for them (so they 
could be updated separately, have separate testing and inclusion process 
and to separate fields of interests between devs) and to stop being 
broken by changes in some packages outside the consolidation,
so so that main distribution building guys that release whole distribution,
should not have headake with separate consolidation issues.

Does that consolidation way sounds usefull enough for people that shoud 
do releasing of OI releases and maintain and patch them with update for 
a long time
and what are upsides and downsides on working with everything without 
consolidations (one of them is surely OS/Net-Illumos one), should be 
discussed,
in the light of how it is done upstream for consolidations we use and
what good affect could it have right now and what affect could it have 
with project grow
in terms of managing many more interdependent software packages and 
people/teams in the future?

> 3) providing stable desktop environment for developers/system 
> administrators - we should

> For now I would even give point 3 more priority then 4, because we 
> don't have strong advantages over other modern server OS, but OI is 
> the only decent illumos-based desktop OS.
> Don't kill me for the last paragraph :)
I really actually *like* your last paragraph! :P

My humble opinion is that DE is the prerequisite to actually have server 
use, and migration to OI from other platforms - if server admins can 
count on having working DE for them on server.
(Also politely asking not to be killed for this :P)