[vbox-dev] Patch to support installation on non-Sun/Oracle Solaris hosts

[Ramshankar]

Hi Jim,

> Hi Ram,
>
>
> That's what I researched originally. The problem is, these "uname" 
> identifiers are not quite constant (and in my own build of the OS/Net 
> gate I can define anything I want).

I'm sorry but I disagree with the expectations here.  If people want to 
make their OS practically unidentifiable, then the onus is on them to 
deal with the consequences.  If someone can fake up their own uname 
while building their own kernel, they can also break the kernel package 
FMRI any way they choose. This is not something we want to support.

With this being case, we should be able to use 'omni*' or 'oi_*' or 
'illumos*' and use 5.11 snv_151 version compatibility.

Regardless, I hacked up a patch last week trying to fix up the FMRI 
parsing (rest of the stuff is untouched).  I'm attaching the patch here 
(you might have to manually apply it, as it's pretty small).

Let me know if this satisfies the requirements for supporting the 
distros in question. This patch doesn't do the uname simplification I 
mentioned above, so there's no guarantee that I'll be applying this 
patch if there is a simpler solution.

> My patch did include variants for unames reported by OmniOS, OI "dev" 
> and OI "Hipster", per these examples:
>
>
> omnios# SunOS HOSTNAME 5.11 omnios-c4ba593 i86pc i386 i86pc
> oi-dev# SunOS HOSTNAME 5.11 oi_151a8 i86pc i386 i86pc
> oi-hip# SunOS HOSTNAME 5.11 illumos-1d3f896 i86pc i386 i86pc Solaris
>
> For the moment, they do report "5.11" as the kernel level (but so did 
> SXCE for most of its history - and before it had crossbow for example, 
> as well). Kernel versions are tagged as "distro_version", 
> "distro-commitid" or "illumos-commitid" in just these few examples. 
> Again, a custom-kernel builder could mark it to be anything else.
>
> There is likely no possible universal automagic solution for this 
> (hence the fallback to touchable files to satisfy everybody who does 
> not fit our patterns), just support for the most-likely situations to 
> require nothing else than a "pkgadd" and do what is appropriate.
>
>
> Jim Klimov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vboxconfig.diff
Type: text/x-patch
Size: 4227 bytes
Desc: not available
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20150702/9400ca0a/attachment.bin>