[pca] --stop option not stopping?
Sebastian Kayser
sebastian+pca at skayser.de
Tue Apr 7 11:53:52 CEST 2009
Martin Paul wrote:
>> should the --stop option apply to a simulation also? I just stumbled
>> upon --stop, but it neither stops a simulation nor does it stop a
>> listing.
>
> "stop" and some other options like "ignore", "minage", etc. only work
> when a patch group like "missing" or "installed" is used. When
> specifying explicit patch IDs, like in your example, these options
> aren't honored. The idea is that pca assumes that you really want to
> list/download/install patch X if you're specifying it by it's idea, no
> matter whether stop/ignore/etc. are set up somewhere.
Thanks for the clarification. Now i remember that i might have read that
somewhere sometime. In case the the current behavior is kept, how about
a heads up to the user upon invocation (--stop, --ignore, ... don't work
with an explicit patch list) or a prominent warning somewhere in the man
page?
> It's not the first time this issue is mentioned, and I'm not 100%
> convinced myself that the current behaviour is optimal, but the same
> applies to the behaviour that you expected. Is there a good reason to
> run "pca --stop X --install X"?
The patches are the minimum patch requirements for Live Upgrade in a
Solaris 10 SPARC environment [1]. That's why i have a explicit patch list.
118833 gets pulled in by pca as a dependency and requires an immediate
reboot afterwards. From what i understand there would be no harm done
with subsequent patchadds run w/o reboot, because the patchadd utilities
are lofs-overmounted with noops after applying 118833. I just wanted to
tell pca "don't even try it" :)
> With tight manual control over the patch
> list, you probably don't need stop/ignore/etc.
That's what i did in the meantime. I just manually split the patch_order
list in two lists.
Sebastian
[1] http://sunsolve.sun.com/search/document.do?assetkey=1-61-206844-1
More information about the pca
mailing list