Tate, Robert B wrote:
Thank you! I missed that. I would argue that is should ignore it as requested
and then show that the others were ignored also when they were done. Or a
separate option to Force the ignore anyway. I see the reason for not doing it
that way also, but the only problem with that is that (in this case) we end
up with an unbootable system.

I agree that the current behaviour is unexpected; to be honet, I had to take a close look myself to realise it. After looking at the code and thinking about alternatives, I'm still unsure about a "better" behaviour. A "--strict" option could be added, which would enforce strict ignoring, even if a patch is required by another one. Due to the recursive dependency checking, it would be hard to ignore the requiring patch, too, though. So it'll end up with patches in the list which will fail to install because of missing dependencies.

Anyway - the good thing is that such situations usually don't happen - the issue hasn't come up in the last years. This one is kind of special - normally a patch with ill effects is marked as "BAD" and an older revision is reinstated. Then PCA will show the last good revision, and everything is fine. This kernel patch doesn't have a previous revision, and it obsoleted a lot of other patches, which would have to be reinstated as well. Maybe the problem was deemed not to be serious enough, to rectify that amount of work.

I did see a 'whitelist' referred to in the update logs. What is that used
for?

It's used with PCA's "--safe" option. Before installing a patch, it uses pkgchk to see whether any of the files which come with the patch have local modifications. This is to warn you from e.g. /var/yp/Makefile or sendmail.cf being overwritten without notice. There isn't a 100% consistency in the pkgchk database, and the whitelist is used to ignore certain files in the check.

This is a awesome program and has saved my tail on a bunch of systems when
Oracle stopped supporting smpatch on Sol 8 and 9 systems (I still have a few
left).

Thanks!

Martin.

Reply via email to