tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: OS_VARIANT



* On 2016-02-02 at 06:14 GMT, Richard PALO wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Le 02/02/16 04:01, Greg Troxel a écrit :
> > 
> > Jonathan Perkin <jperkin%joyent.com@localhost> writes:
> > 
> >> * On 2016-02-01 at 18:36 GMT, Richard PALO wrote:
> >>
> >>> I'd like to propose making OS_VARIANT multi-value.
> >>>
> >>> In particular this is useful for SunOS where currently only
> >>> "SmartOS" and "OmniOS" are listed variants but not "Illumos" as a whole.
> >>>
> >>> The basis is simple, if ${OS_VERSION} == "5.11" and there is no "Oracle" found
> >>> in /etc/release, then the OS_VARIANT would be [initially] "Illumos".
> >>>
> >>> Subsequently, "SmartOS" and "OmniOS" can tack onto OS_VARIANT with '+=' instead of '='.
> >>
> >> I don't like the idea of changing the variable type and overloading it
> >> with multiple meanings, but I agree we could do with a way to identify
> >> the different vendors, so maybe just introduce a new variable like we
> >> did with LOWER_VARIANT_VERSION.  Maybe OS_VENDOR?
> > 
> > I agree, more or less.   My big point would be that Someone needs to
> > decide if a proper OS_VARIANT is Illumos or if SmartOS and OmniOS are
> > proper values.  With the various forking and branding going on, this
> > seems more important.
> > 
> > The other logical point is to have a full-blown hierarchy of names, as
> > an arbitrary tree, but that seems unwarranted.
> > 
> > Richard: What problem are you trying to solve, and what are the other
> > candidate approaches?
> > 
> 
> Well, in «our» case, perhaps OS_VARIANT should be "illumos"
> 
> I see "OmniOS" and "SmartOS" more as OS_DISTRO (or something to that tune)
> (If using OS_VENDOR, it would be respectively "Omniti" and "Joyent", I believe)
> 
> Actually, looking more closely at the two cases of "OmniOS", I think they are both unnecessary
> as readline builtin.mk checks should be sufficient and tcsh should probably have a builtin
> check to avoid the type of construction that is used (i.e. not using PREFER_NATIVE+= or equivalent)
> 
> Also, many of the "SmartOS" usages, such as replacing '/usr/ccs/bin' with '/usr/bin', 
> should simply be generalised for "illumos" (if not for all of SunOS 5.1[12])

If that is indeed true then yes let's do that.  The reason I went for
the OS_VARIANT=SmartOS stuff in the first place was to avoid breaking
other illumos distributions, but if they are all doing the same things
in all the ${OS_VARIANT} == "SmartOS" sections then we should just use
"illumos" and be done with it.

I'll prepare a patch and a bulk build on SmartOS for this, and then
you can test it on OmniOS.

> The next task is merely chucking all the overkill out of mk/tools/tools.SunOS.mk 
> (such as all the *gnu* biz where I already override the bulk of TOOLS_PLATFORM.*) and
> doing the right thing via mk/tools/* and PREFER_NATIVE (if absolutely necessary or wanted).

Not sure exactly what you mean here.  If you mean getting rid of the
/usr/gnu stuff then it'd be a +1 from me, but we already don't ship
that stuff in SmartOS so it wouldn't affect me.

Thanks,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index