William Schumann wrote: > So, to try to summarize: > > INST_RELEASE is still a relevant source for release information, in > particular, for Target Discovery to use to report to the person > wishing to install Solaris about existing Solaris instances on the > computer. uname(1) is not useful for this, since it applies only to > the running system. /etc/release does not have a particular syntax > and is really only human-readable. Other Unixes or Linux don't seem > to provide this in a standard way. > > INST_RELEASE might be of some use on a running system, but none in > particular have been made concrete. > > The original build ID may be somewhat irrelevant as packages are > updated, so the build ID will in INST_RELEASE will be updated when a > "pkg image-update" is run. > > More detailed package info would also be useful, but with the new > packaging system, the metacluster concept will disappear, and > representing packaging on a system here is nebulous and calls for > further consideration. > > Sundar Yamunachari offered: >> Build id works well if it keeps on going up like Solaris Nevada. For >> Solaris 10 updates, it doesn't give the complete release information. >> May be we can have a major, minor and micro release fields to >> identify all releases. > What would distinguish micro releases from minor releases? Could you > give an example of a micro release? My usage of Major, Minor and Micro release doesn't conform the Solaris definitions. Even though OpenSolaris is not going to follow Solaris 10 update model, I am giving an example from Solaris 10. If the system has Solaris 10 update 2 build 6 (may be beta), how will you represent this release?
Thnaks, Sundar > > Bart Smaalders suggested named boot environments, which sounds > useful. This might be suggested in Snap discussions, since it would > be dependent on the new BE functionality. I will bring this to the > group. > > There was no interest expressed in dates (date of installation, date > of last package upgrade,...) or general installer comments (e.g., > contact information). > > The proposal is pretty much as I put it originally, with minor changes > only. > > Currently, INST_RELEASE looks like this (Nevada): > $ cat /var/sadm/system/admin/INST_RELEASE > OS=Solaris > VERSION=11 > REV=0 > > Proposed additions: > Solaris build ID: > BUILD_ID=<build identifier> > > The build ID would be updated with each "pkg image-update". > > Still up for discussion is a micro release identifier. > > Functions to manage INST_RELEASE during install include: > int set_release_info(const char *field, const char *value); > char *get_release_info(const char *field); > int write_release_info(const char *root); writes INST_RELEASE > according to current settings. > void dump_release_info(void); write to stderr > etc. > These functions are to be made available in a library in the SUNWsolnm > package. > > William Schumann
