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
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev
