On Tue, 20 Feb 2007 23:26:33 -0800 (PST) David.Comay at Sun.COM wrote:
> >> I guess I'm wondering though what sort of release values are used with
> >> other systems? Could it instead be based on something like (major # *
> >> 100) + (minor #?)
> >
> > In any case this would AFAIK require major changes in the upstream
> > sources (and we try to not fork() the code, remember ?) because AST is a
> > large codebase (ksh93 is only a tiny piece). It's possible to change but
> > it may require some time (the problem is that this value comes from the
> > base architecture directory (e.g. if you build the upstream package the
> > generated binaries and includes are stored in
> > arch/<value>/(bin|include/ast|libs|etc)/ where <value> matches the value
> > we're currently talking about) and I am not sure which code depend on
> > this (we're talking of a codebase which matches OS/Net in size) ...) ...
> Sorry, I still don't quite understand those the difference between
> using both components or just the minor part since in the ends it's
> just a number that appears after the "sol" part, right?
> However, if the ATT code already expects this to be "11" for a SunOS
> "5.11" version, then I'm fine with what you have now. If you could
> pass upstream the feedback, though, that this could break if the minor
> part ever reverts to "0", that would be appreciated.
the HOSTTYPE value (.../arch/$HOSTTYPE/...) used in ast packaging is for
differentiating incompatible .o/a.out formats/compilation-systems
it lies somewhere between "i386" and "uname -r" or "gcc -v"
its not a place for version numbers unless version numbers illuminate
binary incompatibility
also, uname(1) output for the most part is useless inter-vendor
the explicit spelling of HOSTTYPE is used in a few places in the
build system like
"sol*.*" :NOOPTIMIZE: sfrd.c sfvprintf.c
which means "don't optimize compile these on solaris"
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
