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