Bart: of course, thanks for the correction, sorry to give bad info.
Will: answer inline.
On 03/26/10 12:29 PM, Will Fiveash wrote:
> On Fri, Mar 26, 2010 at 09:10:27AM -0600, Mark J. Nelson wrote:
>> On 03/25/10 05:19 PM, Will Fiveash wrote:
>>> On Mon, Mar 22, 2010 at 06:08:01PM -0600, Mark J. Nelson wrote:
>>>> And for the record, I'll take this away as useful clarification for the
>>>> README.pkg: we need to be more explicit about doing all of the build
>>>> operations from usr/src/pkg, and about mapping package names to manifest
>>>> files in usr/src/pkg/manifests, and that it's the file name (not the
>>>> package name) to use for PKGS.
>>>>
>>>> When the doc was written, they were all the same (package and file
>>>> names), so we missed making that distinction.
>>>
>>> One other thing, here is what I'm planning on doing to just update the
>>> Kerberos
>>> binaries on a test system (assume I've already done a nightly in my hg repo
>>> with the -p option):
>>>
>>> 1. build krb binaries with debug options using install target for dmake.
>>> 2. cd usr/src/pkg; dmake service-security-kerberos-5.pub
>>> system-security-kerberos-5.pub
>>> 3. on the test system do a pkg install service-security-kerberos-5
>>> system-security-kerberos-5
>>>
>>> Am I missing anything?
>>
>> Only a little bit: the third step will behave differently in incremental
>> and clean build cases. For an incremental, where you already have a
>> package repostory from a full build, it will result in an image-update;
>> that's fine.
>
> My intention is to always prep my hg repo with nightly including a -p
> flag. My next issue is that after reading pkg(1) and beadm(1M) it is
> still unclear to me whether doing a pkg image-update to update my test
> system in the scenario described above will result in a new BE with my
> new debug bits or will just update the existing BE. Can someone clarify
> this for me?
That's actually the best scenario.
You should use image-update, and it will create a new boot environment
that will have the full contents of:
A. All of the latest versions of non-osnet consolidations from your
opensolaris.org publisher
B. The baseline version of osnet packages from your workspace
C. The specific updated packages from your most recent incremental
build in usr/src/pkg (as you described in step 2 above)
Now your base system has a stable boot environment, plus a test boot
environment, and you can reboot from one into the other and back.
>> For a clean build, you'll have trouble installing them,
>> unless your base system is already at the same version. That's because
>> the osnet-incorporation will force all of the osnet packages to be at
>> the same version. The solutions are either go ahead and do the full
>> packaging build mentioned above (good, and not terribly expensive) or
>> "pkg uninstall osnet-incorporation" (bad, and way too easy to screw up a
>> system).
>
> Given I need to run a nightly to initialize my hg repo so I can build
> krb bits I won't be trying to create packages in a hg repo that hasn't
> had a nightly -p done prior.
Good; see above.
