On 07/27/10 00:07, Liane Praza wrote:
On 07/26/10 04:44 AM, Gowtham T wrote:
Hi,
I am working on SEA code removal from Nevada which involves file removal
from ON and SFW gates.
Some, daemons and SMF services are removed. And the changes also involve
removing some packages, modifying some others.
Removing sea, sea-config, mibiisa
Modifying library/lint, net-snmp, net-snmp/addons
The ON gate on nightly generates IPS packages and the SFW gate generates
SVR4 packages.
To test my package specific changes, I created a custom repository with
the modified/obsoleted packages along with necessary changes to
consolidations. The commands run are as below
For ON, osnet-incorporation should have been updated for you when you
did the EOF as is described in
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/pkg/README.pkg
in the EOFs and Removals section. Please make sure you've followed
those instructions carefully. Never ever hg remove a package manifest
file in ON.
Yes. I have followed the steps mentioned in the above url. The packages
I have removed are now created as obsoleted packages during my nightly
build.
I have checked the manifests of those packages and they are good. But,
the osnet-incorporation still has the entry for obsoleted packages.
I am not sure where it gets those entries from.
I have done all the steps under "EOF/Package Removals" section of the
README. Updated the manifest of pkg being removed and its ancestors.
But, still the osnet-inc has the package entries of obsoleted pkg.
Because of those entries in the nightly osnet-inc, the onu fails as it
cannot do a pkg image-update.
Webrev url at:
http://jurassic.eng/net/10.12.184.118/builds/gowtham/seach/webrev
For SFW, simply doing the normal package EOF process (mail to RE,
remove the SVR4 package data) will cause the right thing to be done by
David Comay during the build where your SFW changes are integrated.
The other test I'd suggest is that if you aren't intending on creating
a cross-consolidation flag-day, please make sure you test *just* your
ON changes without having upgraded your test system to your SFW
changes. That is, make sure that life for normal ON developers will
work. For SFW developers, where they aren't yet using IPS packages
natively, there isn't as much you can or need to test.
I think onu will achieve the same results.
Regards,
Gowtham
Finally, I suggest searching ipkg.sfbay/dev for the packages you're
obsoleting to make sure that there's nothing else surprising that's
depending on those packages.
I had to modify the consolidations osnet and sfw because to upgrade my
custom packages, I had to
remove those entries from the consolidations. Otherwise, pkg command
would not allow them to be upgraded.
While that's a workaround, the WOS constructs things to incorporate
the obsolete packages at the obsolete version. That's what the ON
instructions described above make sure happen.
I am not sure if this testing done is sufficient. So, I wanted to know
what sort of
testing should be done when IPS/SVR4 packages are obsoleted/modified?
And, how do u test a complete image upgrade of a system to the latest
modified packages? Do I need to setup a complete to do so?
You can easily do this in ON by installing a system with the last WOS
build of OpenSolaris normally, installing the package you expect to be
removed, and then using onu/image-update to update to your built ON
repository. If you've done everything correctly, the files/services
you deleted will no longer be on the system, and the packages you've
obsoleted will no longer be there either.
liane
_______________________________________________
on-ips-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
