On Mon, Mar 22, 2010 at 10:36:20AM -0600, Mark J. Nelson wrote: > On 03/20/10 10:31 AM, Shawn Walker wrote: > > [moving to on-ips-dev, on-discuss BCC'd] > > Thanks. Keeping on on-ips-dev, swalker bcc'd... > > > On 03/19/10 06:59 PM, Will Fiveash wrote: > >> I've looked at all the new IPS docs for the ON developers but I am still > >> unsure as to how to efficiently update the > >> pkg:/service/security/kerberos-5 pkg with a debug version of the > >> mech_krb5.so.1 lib so that I can update a test system with those bits. > >> I assume that I need to cd to usr/src/lib/gss_mechs/mech_krb5 and do a > >> dmake install with debug compile options but I am unclear as to what > >> exactly to do next to get the pkg built so I can install it via IPS on > >> my test system. And on my test system it would be nice to know how I > >> should install just that krb pkg with the debug bits. Advice > >> appreciated. > > For debug bits, you're correct: just make sure that's what's in your > proto area before you do your packaging. In most cases, that should > just mean "do a debug build, using either the -D option to nightly, or > interactively using the -d option to bldenv." If krb5 is different, I > trust that those details are not the real question here. From here on, > I assume that either your build will generate what you want, or you have > made sure that what you want is in your proto area.
Thanks, I understand how to generate debuggable user and kernel binaries. > To get those bits into packages, your options are, in order of ease of use: > > 1) Just let nightly build the repositories for you > 2) Using bldenv: cd usr/src/pkg; dmake install > 3) Using bldenv: cd usr/src/pkg; dmake install PKGS="fu bar" I am confused as to what package name to use for the Kerberos packages. On snv_134 pkg list displays service/security/kerberos-5. Is that the name I should use above? If not this should be more clearly explained in: http://src.opensolaris.org/source/xref/pkg/on_ips/usr/src/pkg/README.pkg In the Incremental Builds section it would be good to provide more explicit detail and or a couple real world examples. Also note that any references to repositories should be clarified as to whether those are Mercurial repositories or IPS repositories. > 4) Using bldenv: cd usr/src/pkg; dmake fu.pub bar.pub SUPPRESSPKGDEP= > > Options 1 and 2 will give you full repositories, and you'll want to > image-update to their contents, either manually or using the onu script. > > Option 3 will give you a full repository, but the "osnet-incorporation" > will ONLY constrain the packages you specify. ("fu" and "bar" in the > example, but I would expect you to substitute the names of the packages > you want here). > > Option 4 will only publish the packages you specify. > > I recommend against 3 and 4, because they defeat the package dependency > generation and enforcement done by pkg(5). Any testing you do under > these conditions is on an unsupported (and undeliverable) configuration. > > Option 1 will, before publication, clear out the $PKGARCHIVE. The > remaining options will not, but you may certainly do so manually, and > that will result in less confusion if you then attempt to inspect the > resulting repositories, and differentiate between packages based on > timestamp. Let me clarify what I'm looking for by providing more context. Because I work often with user space binaries where there are a number of layered libraries I would: 1. build all those libs and whatever else I was debugging with debug flags on so I could use dbx on them. 2. do dmake installs for those binaries to update the proto area. 3. rebuild just the packages that contained those binaries 4. do a pkgadd of just those packages on my test system using overwrite mode to avoid creating more than one package instance. This was relatively efficient because I didn't have to rebuild all packages when I updated the binaries I was debugging nor was I re-installing the test system. Is there a way to do the equivalent with the IPS package system? -- Will Fiveash Oracle Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com http://opensolaris.org/os/project/kerberos/
