On Thu, 27 Jan 2005 21:52:18 +0100, Aurelien Bompard <gauret@xxxxxxx> wrote: > > Another argument which has been made for continuing in this fashion is > > that standardizing on using sonames in all library packages > > potentially lowers the bar to backward-compatibility cruft. Such > > libraries would linger in an unknown maintainership state and be > > difficult to drop at any point because there will always be users who > > are using legacy application that needs that legacy library. > > Very true, and that's what Axel's proposal to introduce a virtual Provides > is trying to solve. With it, a simple "rpm --whatprovides > shared-library-package" returns all the library packages. I dont think the shared-library-package provides solves the cruft problem from the project perspective. From the user perpective yes the provides hack will be a somewhat useful mechanism for users/admins to cull cruft from their boxes. But i don't think thats what Ville had in mind when making the argument. I think Ville was talking about how the project as a whole prevents itself from accumulating layers and layers of library cruft that become harder and harder to maintain as time goes by because there is less and less upstream interest in maintaining the aging codebase. Its easy to package up an old library and offer it.. it gets harder and harder to 'maintain' such a package with critical and security related patches if the upstream development interest has dried out. I think Ville's arguement is aimed at making sure that whatever policy Core is using doesn't encourage the accumulation of difficult to maintain legacy libraries for which users are expecting to be able to be maintained at a high standard. > > Now we need a way to actually expire the old libraries. Proposals have been > made in this direction to flag what the user has directly asked for and > what was brought in as a dependency. In which case the library could be > garbage-collected (if nothing depends on it anymore). > This would be great, but I don't know how much work it would require to > implement it in rpmlib (and in wrappers maybe ? maybe not needed) Again these solutions have focused on the user's perspective of how to garbage collect unused libraries. That is not the crux of my concern. I've been trying to talk about a mechanism by which the package authors can expire a library.. thus notifying ALL users of that particular package that the author is no longer going to be providing any maintence for that library. And when the package authors have decided to expire the library.. the secure thing to do is to remove that library from the system regardless of what applications are still using it, until a new package author can be found for that library who is willing to 'maintain' the library. This is what effectively happens when core drops libfoo.so.1 from package libfoo and adds libfoo.so.2 instead. When the installer is used to upgrade to the new Core, any package that depends on that old libfoo.so.1 library breaks or gets removed. Sucks for the user that doesn't care about running vulnerable code.... sucks marginally less for a user who wants to make sure they aren't going to be opening themselves up to a future vulnerability that won't get patched with an update. The garbage collecting ideas address a different problem altogether than the 'expiration' issue i see the current core naming scheme being implicitly used for in some situations. Every if you garbage collected.. you still don't have a clue about whether the original author is going to be issuing updates anymore for a libfoo1 package that you are still using for a number of applications in the soname in packagename scheme. Keeping the libfoo package name across soname versions implicitly defines an enforced expiration policy by the package author. -jef
