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

Alexander Pyhalov alp at rsu.ru
Wed Oct 9 18:10:28 UTC 2013


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.


>>   As for some reasonable policies - if someone could propose them, I'd be glad
>>   to hear.
>
> You mean policies how OI discusses changes, improves drafts and aggrees them?
> Or something else?
>
> If OI knows what the target for OI is, then one could break down
> how a general discussion for changes should look like, who/how can
> enter changes, how they get approved and supported by all developers.

Yes, I mean policies on OI development - how reviews are made, what 
repositories are supported, what changes can be pushed an so on.

As for general direction, for now I see the following targets:
1) self-hosting and ability to recompile world with GCC
2) making build process as easy as possible - ideally "make world"
2a) moving away from legacy consolidations to single build system, so 
that every part can be modified without headache
3) providing stable desktop environment for developers/system 
administrators - we should look at updating JDS, perhaps bringing XFCE 
or other lightweight DE (dreams, dreams)
3a) provide necessary build environments for illumos development
4) provide decent server environment.

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 :)
-- 
Best regards,
Alexander Pyhalov,
system administrator of Computer Center of Southern Federal University




More information about the oi-dev mailing list