<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Martin,<br>
<br>
Martin Paul wrote:
<blockquote cite="mid:4EAAA62E.4090703@par.univie.ac.at" type="cite">Hi
Don,
<br>
<br>
<blockquote type="cite">After investigation it turns out that the
database could not handle an update to the actual 'requires' field, as
there is an integrity check in place to ensure that the 'requires'
field is consistent with the info in the pkginfo SUNW_REQUIRES filed
(which patchadd uses to resolve patch dependencies).
<br>
Essentially, this check prevents us updating the database's patch
requirements.
<br>
</blockquote>
<br>
So the obvious solution - updating the SUNW_REQUIRES field itself - is
not an option either, I guess?
<br>
</blockquote>
Not possible or desirable.<br>
<br>
The patch deliverables cannot be changed once a patch is submitted for
testing. This is to ensure that we test what we release and release
what we test.<br>
This also ensures that only one version of any given patch can exist.<br>
<br>
This is one of the fundamental rules regarding our release management.<br>
<blockquote cite="mid:4EAAA62E.4090703@par.univie.ac.at" type="cite"><br>
Or wouldn't it be possible to add information about 126677 to the patch
database? At the end, not much more information than "obsoleted by
124628-03" would be needed, which would then show up in patchdiag.xref,
too?
<br>
</blockquote>
This is an option that we are investigating.<br>
<br>
The problem we face is that our process needs to be extremely robust,
so any solution that we try to put in place is future-proof as well as
backward compatible, so nothing gets broken (or abused down the line,
leading to further complications). <br>
In addition, we need to be very careful that all the systems that use
the patch metadata we generate (eg. Oracle Enterprise Manager Ops
Center, smpatch, MOS) do not get negatively impacted by any changes we
make.<br>
<br>
What I'm trying to convey is that it is not just a case of seeing a
problem and putting something in place to fix it; we need to look at
the problem from all angles and patchdiag is only one small cog in the
wheel.<br>
<br>
Best,<br>
-Don<br>
<br>
<blockquote cite="mid:4EAAA62E.4090703@par.univie.ac.at" type="cite"><br>
<blockquote type="cite">Hope this makes sense!
<br>
</blockquote>
<br>
Kind of. Although sometimes I'm glad that certain things don't make
sense to me; understanding too much might lead to insanity :)
<br>
<br>
Martin.
<br>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://www.oracle.com/"> <img
src="cid:part1.09090707.02040500@oracle.com" name="graphics1"
align="bottom" border="0"></a> <br>
<font face="Verdana, sans-serif" size="2"><b>Don O'Malley</b></font><br>
<font color="#666666" face="Verdana, sans-serif" size="2">
Manager,Patch System Test<br>
Revenue Product Engineering | Solaris | Hardware <br>
East Point Business Park, Dublin 3, Ireland<br>
Phone: +353 1 8199764 <br>
Team Alias: <a href="mailto:rpe_patch_system_test_ww@oracle.com">rpe_patch_system_test_ww@oracle.com</a><br>
</font> </div>
</body>
</html>