Jesse Keating wrote: > On Wednesday 23 August 2006 15:33, Kai Engert wrote: >> But there is absolutely no real need to rebuild gaim, because of NSS' >> promise that you are allowed to drop in (at runtime) any later version >> and it will run just fine. >> >> I believe your alternative proposal unnecessarily introduces the need to >> rebuild applications. Let's suppose we have 10 applications that link in >> NSS, I believe your proposal requires us to rebuild all those 10 >> applications, each time a NSS release with additional symbols gets >> released. >> >> And it would make our life more difficult, because of having to maintain >> the versioned .so filenames as a difference to the upstream project. >> >> If I misunderstood, please elaborate. >> >> I believe the earlier proposal to dynamically adjust the Requires: for >> the minimum allowed NSS version is much simpler, it causes no manual >> work, a one time spec file change will fix it for all future releases. >> And it will minimize the amount of packages that need to get rebuilt and >> will actually depend on the more recent NSS releases - to only those >> applications that got rebuilt for a reason. > > How do any other versioned libraries manage this? This is not a new problem. > Why does NSS have to be special and continue using an unversioned library > that could have any unknown symbols in it? It seems like you're working > around NSS's refusal to play nice like a good library. While the workaround > is simple, it does not solve the problem for other packaging systems or > direct compiles. The work around is a temporary thing until the REAL problem > is fixed upstream. > Actually afaik gnome and gtk have the exact same problem (they are fully backward compatible but introduce new symbols making apps using these new symbols break on older version), but there we've been plastering over the problem by manually adding Requires to packages. I like the idea of automaticly doing this. Regards, Hans -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
