[oi-dev] sigcpp issue

[Thomas Wagner]

Hi Alexander,

[...]
>  As always, I'm the one to blame for it. However, this particular conflict 
>  could be caused by directory permission.

True, permissions differ. the pkg contents dump of pkg:/sfe/library/g++/sigcpp
prints what we default to.  It should be in sync with what is in /usr.

>  What permissions are set for /usr/g++ subdirectories in SFE?
>  I'm going to commit the following:
>  https://github.com/pyhalov/oi-userland/compare/sigcpp
>  Is anything missing?
Hm. I had a quick look, and I believe directory be root:bin
and files as well. I would just duplicate for /usr/lib/g++ what
is set for /usr/lib. I have no running OI instance at hand 
to verify.
 
I believe the next error printed will be that both packages
can't be installed together (and they can't/shouldn't).
So it is still necessary to move out the SFE package if
is is for a more recent osdistro like oi151.8 .

This is something we (SFE) have to live with, as we are
mainly a "guest" ontop of a stable distro (OI, Solaris 11,
probably others). Distro do change over time and should
change. Therefore it is natural to get packages added
to the distro we already have in SFE and we give way.

>  As I understand it, /usr/g++/ libraries is a temporary solution which allows 
>  us to avoid breaking Sun CC-compiled programs.
Yes, avoid breaking studio compiled programs using C++ libs
from the distro.

Temporary solution, well, only under conditions. OI can either
use it permanently or move over to /usr with advantages and
disadvantages.

For SFE, the idea is still a non-temporary one. For SFE, it adds
an independent stack built with g++ if that is necessary.
And is was neccessary because it was not practicable to port 
100% of g++ code over to studio compilers.

The idea of /usr/g++ is documented on the pkgbuild.wiki.sourceforge.net
and is the storage location for the case one needs two or more 
independent stacks of C++ libraries. It also covers /usr/stdcxx.

We use studio compilers as in the past defaulting --prefix to /usr,
gcc compiled software without C++ can got here as well. 

But once g++ comes into the mix, you get into all sorts of C++ lib-
raries found and mixed up. This is somewhat permanently solved 
by the separate stacks for g++ compiled software and all stuff
building ontop does an -R/usr/g++ and -L/usr/g++ first to 
find g++ software from those directories.

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

If the OI developer crowd decides to discard that part of compatibi-
lity, then I believe this will be a well-thought and well documented
feature of a future OI distro release.

 
>  I've tried to discuss sigcpp on Developer ML and IRC channel. I've heard 
>  several opinions. And library was committed at least a week after 
>  discussion.
>  So, there are two reasons: insufficient testing and the main one - nobody 
>  cares.
This case is probably just discussed because it what there at that point
in time. I see this as a more general problem, and not a problem of
that particular library, so no worries.

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

All with keeping a good balance between process complexity and keeping
developers happy when entering changes. But I believe quality can
only increase if brains connect. And thats maybe the root cause.

Thomas