Hi Nick et al,
see my comments inline:
Nicholas Solter wrote:
> Thorsten,
>
> This looks really good. Thanks for all your hard work on it!
>
> Here are a few comments and questions:
>
> usr/src/ipsdefs/Makefile
>
> I think SUNWscte and SUNWsctx are required for running SCATE tests (at
> least the fault injection tests). We should consider putting them in a
> repository for a debug build.
How are they getting installed today? Neither the JES Installer nor
scinstall would do that today. They are not listed within any
pkgdefs/dot.* file.
Would we plan to publish them on an external repository?
Will the rest of the test suites be available from the repository?
If the answer to both is no, whats wrong with using the SVR4 packages?
> usr/src/ipsdefs/Makefile.com
>
> Can you add some comments here explaining the format of the version
> string, and also the debug/nondebug and RELEASE_ENG modes?
Will add a comment.
> I notice that you've provided ipsdefs/ conversions of even those
> packages that we don't currently send to the repository. I guess that's
> fine.
>
> General:
>
> It looks like there's no rule in the usr/src Makefile structure to build
> ipsdefs. Only if using nbuild will it build ipsdefs. I guess that's ok.
I thought we can add such a logic once we finalized the ipdsdefs
structure (including the script logic and the refactoring).
> I see that jfreechart depends on pkgdefs being built. That's probably
> not going to work for the long-term, but should be ok for now.
Once we decide to not build pkgdefs for OpenSolaris, we need to create
similar logic within the ipsdefs directories for freechart, yes.
> I'm not sure that lumping derby and telemetry in with cmass is correct.
> Isn't cmass just a framework that's used by the SCM and other stuff? But
> the derby and telemetry packages are for ganymede.
Well, I did take that logic from
usr/src/pkgdefs/dot.clustertoc.sun_cluster.i386.Sol_11.osdist:
# Sun Cluster Manager Components
#
CLUSTER=SUNWCcmass
NAME=Sun Cluster CMASS components
DESC=Sun Cluster Manageability and Serviceability stack components
VENDOR=Sun Microsystems, Inc.
VERSION=3.2
SUNW_CSRMEMBER=SUNWscmasa
SUNW_CSRMEMBER=SUNWscmasasen
SUNW_CSRMEMBER=SUNWscmautil
SUNW_CSRMEMBER=SUNWscmautilr
SUNW_CSRMEMBER=SUNWscderby
SUNW_CSRMEMBER=SUNWsctelemetry
END
If you think this belongs elsewhere, lets address this during the
refactoring then. I am not an expert on those packages and thus did only
take 1:1 from whats there in pkgdefs.
> What's the rationale for creating group packages for single packages
> like agent builder and dtk? I'm not saying that's wrong. I'm just
> curious, because I wouldn't have necessarily thought it would be necessary.
Well, we did not talk about how we would like to present the cluster
packages within the IPS packagemanager. My rationale is that from a user
perspective, all the user cares are the ha-cluster-* group packages.
I notice that many existing OpenSolaris packages are sorted into
categories. I do not fully understand the mechanism yet how they get
sorted - there is some logic within
/usr/share/package-manager/data/opensolaris.org* but varous packages set
something like
set name=info.classification
value="org.opensolaris.category.2008:System/HA Cluster"
within their manifest as well.
Note that "System/HA Cluster" is my fictional proposal which does not
yet exist. And it is not sufficient to just define that in the manifest
in order to be recognized by the packagemanager.
The standard SUNW* packages would not have that property set, only the
ha-cluster-* ones, which would then show up within the packagemanager
category "HA Cluster (System)".
> Why is the agent builder (scdev) in the minimal package? Is it because
> it has libdsdev? This might be worth separating out. This is future
> work, I would say, not for this putback.
Right, it would be part of the refactoring work. But note that we can
not just remove it from SUNWscdev. Today SUNWscdev can get installed
stand-alone - and is sufficient in order to create an agent through the
scdsbuilder (be it C-based, ksh-based or GDS based). Without the
libraries I would the C-based option to fail.
If we factor them out, we would include that new package within the
ha-cluster-agent-builder group package. That is one reason why I created
such a group package, even if today only one package is part of that
group. It gives us some flexibility and abstraction.
> Why does the scm group package have only jfreechart? What about the scm
> stuff itself?
Because we don't build the rest of the packages currently on an
OpenSolaris build. That might change after Lucia made the putback to at
least not depend on Lockhart for the cli based wizard. But that is not
true for my workspace.
Again I took the package list to group from
usr/src/pkgdefs/dot.clustertoc.sun_cluster.i386.Sol_11.osdist:
# Sun Cluster Manager Components
#
CLUSTER=SUNWCscvw
NAME=Sun Cluster Manager Components
DESC=Sun Cluster Manager Components
VENDOR=Sun Microsystems, Inc.
VERSION=3.2
SUNW_CSRMEMBER=SUNWjfreechart
SUNW_CSRMEMBER=SUNWscspmr
SUNW_CSRMEMBER=SUNWscspmu
SUNW_CSRMEMBER=SUNWcscspmu
SUNW_CSRMEMBER=SUNWdscspmu
SUNW_CSRMEMBER=SUNWescspmu
SUNW_CSRMEMBER=SUNWfscspmu
SUNW_CSRMEMBER=SUNWhscspmu
SUNW_CSRMEMBER=SUNWjscspmu
SUNW_CSRMEMBER=SUNWkscspmu
END
As you can see SUNWjfreechart is the only package we can build today on
OpenSolaris. The rest is getting omitted.
> What are your thoughts on where to define our intended user-visible
> gropu packages of ha-cluster-minimal and ha-cluster-full? The latter of
> course will include agents. The former could be defined already, though,
> I think.
I would recommend to define those after the refactoring. Maybe we
ha-cluster-minimal will turn out to be equal to
ha-cluster-framework-minimal.
ha-cluster-full should get defined after we are done with the agent gate
IPS conversion as well.
> usr/src/tools/scripts/nbuild.ksh
>
> I'm not quite following the -p logic. What happens if I specify a repo
> URL without -p? Will it still send the packages to the repo?
No. You would then need to go into usr/src/ipsdefs and perform a
"nbmake IPSREPO_URL=<url> install"
in order to send the packages to the IPS repo.
See above for the reason not to include ipsdefs within usr/src/Makefile
for now.
> How about if I specify a URL and -p? It looks like the URL may get
> overwritten, as
> the following code doesn't check for an already existing IPSREPO_URL value:
>
> 1598 # set IPSREPO_URL to default URL if p flag is set
> 1599 if $p_FLAG; then
> 1600 export RELEASE_ENG_BUILD=
> 1601 export
> IPSREPO_URL=${IPSREPO_URL:-"http://localhost:10000/"}
> 1602 fi
My understanding is that IPSREPO_URL will get either an existing value
of IPSREPO_URL, or "http://localhost:10000/"; if empty.
So the default is only set of IPSREPO_URL is not provided explicitly.
Greets
Thorsten
> Thorsten Frueauf wrote:
>> Hi,
>>
>> some time ago I send a webrev with a 1:1 conversion of SVR4 prototype
>> and pkginfo files into the IPS manifest world, along the design we
>> defined at http://www.genunix.org/wiki/index.php/ColoradoIPSBuild
>>
>> I did now refresh that webrev in order to contain some Makefile logic
>> to "build" the ipsdefs hierarchy and actually perform the pkgsend to a
>> configurable IPS repository URL.
>>
>> The changes also provide a start to consider package dependencies,
>> legacy and license actions. There is logic to deal with pkg versions,
>> also in the case for debug builds and developer only builds. I did
>> also introduce some group packages, similar to the "package cluster"
>> definitions we have within pkgdefs.
>>
>> I know this is a huge pile of files, but I would like to putback into
>> the colorado staging gate next week (say Tuesday COB MET), if there
>> are no major objections. There is follow-up work which is dependent on
>> this putback, like dealing with the various SVR4 package script and
>> refactoring the package content into a different structure (like we
>> can now comine the root and usr packages for sure).
>>
>> Of course this is not yet set in stone and has further ToDo items,
>> some of them I capture within the usr/src/ipsdefs/Makefile file as
>> comments.
>>
>> Please review:
>> http://cr.opensolaris.org/~frueauf/colorado-svr4-to-ips-autoconversion/
>>
>> Greets
>> Thorsten
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
