Rich Burridge wrote: > >It would be useful to be specific, either in comments in the code, or in > >the bug, under what conditions each message is emitted, and thus under > >what conditions that snippet of code can be removed. I'd lean towards > >putting this in the code. > > I've done the first part (see new webrev). I also added an example of > each type of error to the comments. If you think this is overkill, just > let me know, and I'll remove them.
I don't think they're really necessary. The code pretty clearly describes what the output will look like. > But how do you determine "under what conditions that snippet of code can > be removed"? I guess what I'm looking for is "using bits prior to build XXX to upgrade to build YYY or later cause this message to appear". This would be due to bugs in the pkg(5) code or the utilities in build XXX combined with package definitions in build YYY which they can't handle. The "package manager or image-update" is unnecessary -- the mechanism is irrelevant, it's the build boundary you're crossing that is. So, for instance, bug 6877673 causes an upgrade to build 125 or later to be noisy because asy got minor perms that update_drv couldn't handle. As long as you're using build 125 or newer to upgrade from, you won't see it, because the bug is fixed in that build, but upgrading from an earlier build will cause the message to appear. And yes, we can only remove the code once everyone's 2010.03 is the oldest supported release, but I'd like to keep that in terms of build numbers as in the previous paragraph. It also sounds like we should be proposing this for a backport to previous releases, so that folks upgrading past build 125 won't have these spurious errors. They're safe, so it's not critical, but it would make for a better experience. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
