Is it possible to dynamize "requires" at RPM build time?

Jesse Keating jkeating at redhat.com
Wed Aug 23 20:09:11 UTC 2006


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.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20060823/b4fba09e/attachment.sig>


More information about the fedora-devel-list mailing list