At least jeremy@ and landry@ got confused about this, so I expect more people to ask.
The algorithms for package updates are a bit complicated, to say the least. When you update a package with shared libraries, those can get split off into a separate package with a .lib name (which is well known). This package can be removed manually later, once a full upgrade has been done and nothing depends on it (it's not done automatically because user-compiled programs may depend on it... I intend to have a pkg_create -u mode (user) to be able to quickly register user programs so that we CAN remove them automatically). Anyways... In the meantime, those .libs* will participate in updates. In modern pkg_add, pkg_add -u will organize packages to update as updatesets: the smallest set of packages that need to be updated together because of interdependencies/conflicts. Guess what ? a .libs-foo-* will always get pulled in when you update foo, because those two packages belong to "the same" software and contain files that may conflict. That's why you'll see lines like .libs-foo-1.0 + foo-2.0 -> foo-3.0 That's because pkg_add needs to know what's going on. What you're not going to see, though, is the creation of new .libs (unless you use -vvv). But that is necessary. That way, if you need to downgrade back from foo-2.0 to foo-1.0, pkg_add knows enough about it to be able to merge back .libs-foo-1.0 into foo-1.0 instead of complaining about a conflict and stopping. I should probably show the creation of new .libs? that might make things more simple to understand. What happened is that this algorithm evolved, it's one of those "details" I hadn't figured out yet when we embarked on correct safe updates...
