| Hi
I would like to suggest ya'll consider other methods to install.
The problem with your current method is that setld verifies of
files on the kits complains about your files due to the ammount
of file movement done in your scps.
setld verify is the easiest way for folks to check if what
is on the system has been changed from what was distributed.
sys_check does these verifies.
http://www-unix.zk3.dec.com/tuning/tools/sys_check/sys_check.html
Another problem is that folks see Version xxx of clc (which supports
multiple versions of digital unix), so they don't re-install it after
upgrades (because they think it is the same version) , when in
reality there are multiple version in the same kit.
I would rather see you have 2 kits, one for V3.2x, and the other for
V4.0 with different versions so that noting this is easier.
|
|
It is VERY possible that the three number version code (OSFSUBSETXXX)
may change throughout the development cycle of a product. It doesn't
happen often, but I have seen it occur more than once.
If you have a dependency on the OS version, a much more reliable source
of information are the version.* files under /sys/conf. Probe these
files and concatenate the information you need to determine the current
OS version installed on the system.
/sys/conf/version.type Field Test (T)
SSB (V)
Development (X)
/sys/conf/version.major Release major number
/sys/conf/version.minor Release minor number
/sys/conf/version.variant Usually a letter
For example, if the current version is V4.0B, the files will have the
following values:
/sys/conf/version.type V
/sys/conf/version.major 4
/sys/conf/version.minor 0
/sys/conf/version.variant B
You can even isolate the build revision by checking
/sys/conf/version.build 564
|
| Eric --
> The problem with your current method is that setld verifies of
> files on the kits complains about your files due to the ammount
> of file movement done in your scps.
We don't move files -- we point a link at the appropriate object.
> I would rather see you have 2 kits
This is intended as a joke, right? That means the user would need to
select the correct kit to install, and how would they do that? We'd
need to provide instructions in our install guide to tell them what
to look for to make a choice...so we'd be no better off than before.
Please understand -- not only do we need to make a choice between
3.2x and 4.0x, but also between flavors of 4.0x. So it wouldn't be
two kits -- it'd be three, and soon, four. And that's just pre-Steel.
* * *
SMURF::WALLACE --
> It is VERY possible that the three number version code (OSFSUBSETXXX)
> may change throughout the development cycle of a product.
Not good -- I'm not the only layered product that tests the subset name,
and isn't on the same release cycle as the os...
What we need is a decision on the final subset name, sufficiently in
advance that layered products can construct their kits to match.
> If you have a dependency on the OS version, a much more reliable source
> of information are the version.* files under /sys/conf.
Unfortunately, the OS version number is not stable. The release I'm
currently worried about was originally intended to be v4.0c -- it's
now v4.0d, and I can't get a firm promise on that...
Using the subset names to check dependencies is the officially supported
and recommended method for setld'able products.
* * *
The pre-release copies of Ptmin that we've been receiving use OSFBASE425
as the subset name. Can anyone please help me find out if this is the
"real" name? My kit goes to SSB in a little over a week...
Does anyone know who decides on the subset name? Is there someone in
charge of this for *all* Digital Unix releases, or is there someone per
release, or...?
-- Pat
|