> > 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). > > Thanks, > Jim > -- > Typos courtesy of K-9 Mail on my Samsung Android
Hi Jim, 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 quite separate. Regards, Ram. _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev
