.libs handling
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...
Re: .libs handling
On 2011-02-19, Marc Espie es...@nerim.net wrote: 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). FWIW, I have this ugly python script that I wrote some years ago and use regularly: http://www.pastie.org/1583994 It shows all packages which are not required by any other package and lets you remove them recursively. It will also show .libs which are not required anymore. I use it after every pkg_add -ui and every once in a while to get rid of stuff I don't need anymore. It would perhaps be interesting to reimplement it in python using the OpenBSD::Pkg* libraries. Best regards, Jona -- Worse is better Richard P. Gabriel
Re: .libs handling
http://users.cis.fiu.edu/~lusec001/moin.cgi/Software/OBSD_Recursive_pkg_del Luis On Sat, Feb 19, 2011 at 7:03 PM, Jona Joachim j...@hcl-club.lu wrote: On 2011-02-19, Marc Espie es...@nerim.net wrote: 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). FWIW, I have this ugly python script that I wrote some years ago and use regularly: http://www.pastie.org/1583994 It shows all packages which are not required by any other package and lets you remove them recursively. It will also show .libs which are not required anymore. I use it after every pkg_add -ui and every once in a while to get rid of stuff I don't need anymore. It would perhaps be interesting to reimplement it in python using the OpenBSD::Pkg* libraries. Best regards, Jona -- Worse is better Richard P. Gabriel
