Jesse Keating wrote:
On Wednesday 23 August 2006 14:12, Kai Engert wrote:Regarding the way to do it, Rex Dieter proposed to use "nss-config --version". This looks like a good approach to me, because it avoids querying the RPM database while doing an RPM build.Alternatively in OUR packaging of nss, we could move it from .so to a versioned library based on the version of nss we're building. Then have firefox and friends link against the versioned library we create...
In your alternative proposal, would you change the .so name each time a new symbol gets added?
Fictionary sequence of events (in your alternative proposal):- NSS 3.11.1 with nss.so.3.11.1 gets released, along with gaim 1.5, which links against nss.so.3.11.1
- NSS 3.11.2 gets released with nss.so.3.11.2 - nss.so.3.11.1 is no longer available- as a consequence you would need to rebuilt gaim, in order to make it link against nss.so.3.11.2
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.
Kai
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
