2009/12/31 Ben Taylor <bentaylor.solx86 at gmail.com>:
> currently, we have is_nv (just changed from is_nevada), is_osol and is_s10
> in the foss-depend-packages.inc file, and those are used pretty heavily.
> There is some use of the %{with_<OS>}, but we should probably standardize
> on %{is_<OS>} as a matter of the clean up.
>
> base-foss-header.inc appears to include that foss-depend-packages.inc, and
> I'm thinking that we could probably do with some house cleaning of the
> includes
> to fix some logic issues
definitely, in some places it get's quite complex
>
> 1) is_osol was mapping to svn_101b, and I've pushed a fix to include snv_111b,
> but this really isn't effective for anyone on the dev pkgs. ?Adriaan suggested
> looking for /usr/bin/pkg, which works for me. comments?
perhaps
grep -q OpenSolaris /etc/release && echo 1||echo 0
could be used. However both versions would do.
(ugh, does the /usr/bin/grep on S10 support the -q option?)
>
> 2) there's a bunch of complicated %if %{?!_is_nv:1}%{?_is_osol:1} which don't
> really appear to work correctly.
>
> Since we should be setting --with_nevada (guess that should be --with_nv now)
> --with_sol10 and --with_osol, we should probably remove the hardcode of
> %define is_osol 1 and %define _reduced_deps 1 from base-foss-header.inc
> and really do conditional sets.
+1
>
> I am going to recommend that we add the following defines to help building
> or defining files:
>
> Move the %define is_<OS> to base-foss-headers.inc, and extend the logic
> as such:
>
> %if %{is_s10}
> %define not_nv 1
> %define not_osol 1
> %define not_s10 0
> %endif
>
> (and so on for %{is_nv} and %{is_osol} expanding to 1)
> This will allow us to either say:
>
> %if %{is_s10}
> some stuff for S10
> %endif
>
> or
>
> %if %{not_s10}
> some stuff for NV or OSOL
> %endif
>
> but not have to say:
>
> %if %{?_is_nv:1}%{?_is_osol:1}
> some stuff for NV or OSOL
> %endif
> (which in my experience operates not as expected).
>
> Thoughts?
we should somehow distinguish between osol 2009.06 and it's devel
versions (is_osol_dev ?), since some packages are already part of the
system in the latter case.
Now should we automatically assume -devel to be the latest available
build or should we try to have rules like 'if build_number>125'?
I already asked at
http://mail.opensolaris.org/pipermail/sw-porters-discuss/2009-December/001765.html
for hints.
hajma
