[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