[vbox-dev] Patch to support installation on non-Sun/Oracle Solaris hosts
ramshankar.venkataraman at oracle.com
Wed Jul 1 09:13:04 GMT 2015
> Hello Ram, thanks for looking at this :)
> For OmniOS, releases for the past few years have been named 151NNN, with the ever-increasing NNN (current stable 'lts' release is 014 and testing 'bloody' is 015). So the bloody release also seen in FMRI numbers is 151015.
> With OpenIndiana things are a bit more volatile since development concentrated only on Hipster, as the project team pursues large-scale rearchitecture of the distro construstion and for a couple of years they were not at a stable position to pinpoint a numbered release (but since they do provide up-to-date packages, there may now be more users of OI-Hipster than users of the latest OI 'dev'-release). Instead, they occasionally start with a new empty package repository so there is little irrelevant obsolete cruft for pkg(5) to reference and process. Current repo-based version is 2015.0, and IIRC the 1 in FMRI is reserved for unpredicted bumps and/or local user builds to override a central repo, and the next number is a build-farm build number(?).
> Regarding the second question - yes, the purpose is to facilitate installation of those modules (and also I provided a fallback to use touched files for a user to enforce those installations on systems that we can't pinpoint with sed). There are quite a few illumos distros out there, whose packaging I am not intimate with (suffice it to say there are also non-IPS and non-SVR4 distros among them, although the OS/Net sources are common and so likely they would also support loading of these modules).
> Typos courtesy of K-9 Mail on my Samsung Android
This might seem like a silly question, but if the output of 'uname
-something' differs for these distros, can't we just use that instead of
parsing kernel package FMRIs? After all, the whole point of parsing it
is to provide accurate build/release based drivers but since all these
Solaris variants are basically snv_151 level compatible it doesn't
really matter we get accurate major/minor numbers.
It would also make the script a lot simpler and the code path would be
More information about the vbox-dev