[oi-dev] SFE repository an g++ libraries in /hipster

Alex Viskovatoff viskovatoff at imap.cc
Thu Feb 6 16:48:04 UTC 2014


Hello Alexander and Bryan,

On 02/ 6/14 01:59 AM, Alexander Pyhalov wrote:

> Perhaps it would be better to base icu component on SFE spec, however it
> is based on version found in
> https://hg.openindiana.org/upstream/oracle/g11n/g11n-spec . I don't
> understand this stuff enough to say if Oracle patches are necessary in
> later icu versions. They didn't apply, so I went with 4.6. One issue I
> remember - svn version provides some files which should be regenerated
> by hands when using tarball. The only dependency of this library is php
> intl extension, so feel free to update it in oi-userland.
>

I think it would be more work to base the userland spec on the SFE spec 
(which I in turn based on the sfe-kde spec, a project which is now 
defunct, as far as I can tell). I think it makes sense to stick to a 
standard work flow, with Oracle being your upstream if possible. I have 
no idea of why Oracle patches icu.

> nobody cared about Ruby enough to update it.

That's good to know. If a similar thing happens in the future, I may 
update the relevant spec myself. I intend to refamiliarize myself with 
the userland build system and learn how to push changes to hipster's 
userland at some point.


On 02/ 6/14 02:25 AM, Bryan N Iotti wrote:

 > Speaking of Ruby, I'm working with the RVM developers to get it to 
work properly.
 >
 > So far the patches we have allow us to install RVM, download 2.1.0, 
build it and install gems (only caveat is the '--with-openssl-dir=/usr' 
flag at compile time) .
 >
 > The ffi gem however is giving me trouble, must be aa question of 
finding the headers and libraries...
 >
 > Anyway, if that works we shouldn't have trouble having an updated 
version of ruby anymore.

I didn't get the ffi gem to build either, but I ignored that, since I 
was pretty sure I wouldn't need it for what I was doing (using drake, a 
build system that uses ruby).

Somebody told me that ruby 2.1.0 is too new for the enterprise. But the 
SFE IPS package for this calls itself ruby-21, and I think OI should 
call it the same. Thus, an older, more "trustworthy" version of ruby 
(ruby-18, which OI still has) can be shipped together with the latest 
stable one. I'm sure you have set ways of making different versions of 
such packages coexist.

The general point I was trying to make is that OI and SFE should 
practice "coordination", as Alexander said in his earlier post. One 
thing both parties should make an effort to do (which we are obviously 
already doing) is to use the same IPS name if OI (dev as well as 
hipster) ship the same package. My thinking is that in such cases, only 
the publisher should differ. The version hipster or SFE delivers at a 
given point in time is of secondary importance. An sfe-oi IPS package 
can always be rebuilt, in the case that OI starts delivering the same 
package at an earlier version. OI using a different name for the package 
would cause significantly more complications, obviously.

Best regards,

Alex




More information about the oi-dev mailing list