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