Thorsten,
See below.
Thorsten Frueauf wrote:
> 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?
I think you're right. Until SCATE itself is available in IPS form,
there's no sense converting these packages to IPS.
>>
>> 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).
OK.
>
>> 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.
OK. Let's not forget to do it ;-)
>
>> 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.
>
Sounds good.
>> 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)".
>
I'm not convinced that defining the group packages is necessarily
related to the package manager categories, but this obviously needs more
investigation. It's fine with me to add it to the todo list. That is,
not for this putback.
>> 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.
Good point. We may want to put libdsdev in its own package, but this is
future work.
>
>> 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.
OK. That's fine for now.
>
> 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.
Sounds good.
>
>> 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.
>
Right. I missed the conditional setting.
I'm fine with you doing this putback as-is. Everything else can be done
at a later point.
Thanks,
Nick
> 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
>
