Hi,

Sorry for coming to this discussion late.

On 10/14/13 11:13 AM, Alexander Pyhalov wrote:
Hello.
I'd like to know your opinion on the following issue. As we are moving
to gcc-only (or at least gcc-mostly) build in /hipster we have a problem
of providing both versions of Sun CC-compiled C++ libraries and GCC
compiled C++ libraries. The decision is to be made what to do with this
issue in the future. But for the now I'm starting to deliver
G++-compiled libraries in /usr/g++. Evidently, it sometimes breaks SFE.

For example, with recent push of gcc-compiled icu we delivered ICU
4.6.1, while SFE boost package expects to find icu 4.8.1 under /usr/g++.

We need some coordination (for example, on library versions), or perhaps
a separate build of SFE on /hipster. What do you think on the subject?

I am waiting to get a build zone and public repo for SFE builds catering specifically to hipster. There is no question that hipster needs its own build of SFE packages. What remains to be seen is how heavily SFE specs themselves need to be modified to work with hipster. Ideally, as little as possible.

hipster/ is supposed to be bleeding edge. so why does it sometimes deliver packages at versions older than SFE does? icu is a case in point. if you see that SFE is at icu 4.8.1, why don't you just make hipster's icu at the same (or a higher) version? Then nothing would be broken. SFE's boost would simply use hipster's icu lib for its hipster build in that case.

Ruby is another case in point. Just a few days ago, I had to update SFE's spec for Ruby and build it myself, because hipster delivers a version of Ruby that is too old for something I was building. Why isn't hipster at the current stable release of Ruby, which is 2.1.0?

In general, SFE IPS builds for hipster (as well as the SFE specs themselves) should accommodate to new packages that are delivered by hipster which SFE previously delivered itself. (In such cases, as I said, it is preferable that hipster not deliver earlier versions of the same package as SFE delivers unless there is a good reason to deliver an old version.) So, if hipster one day delivers Boost, then SFE will accommodate itself to that. If OI/hipster for some reason decides to deliver an older version of Boost than SFE has been providing and building for some time however, problems may arise.

Best regards,

Alex

_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev

Reply via email to