On Wed, 2008-04-09 at 14:39 +0200, Ralf Corsepius wrote: > > The problem (as described to me) is that if you put them in -static, and > > you BR -static, you then potentially link against /all/ the static > > libraries, even those that have shared alternatives. > How that? Our rule has been that *-static must Require *-devel, i.e. > unless a package is playing nasty games with linking (or this packaging > rule is being obeyed), it will always link dynamically. Since spot was the person who described it to me, perhaps it would be best to get his input here. The way he stated it was that if there were static libs around at link time, they would get automatically linked, even if the didn't want them to. > > > The motivation was > > to isolate the static libraries which have no shared alternative from > > those that do. > > > > We can still "track" things which BR -static-noshared just as easily as > > we can track those that BR -static. > I still fail to see the usefulness of this. > > Our logic had been: Client-packages who intentionally want to link > statically, must BR: *-static, those who don't care should BR: *-devel. > > With your approach above, client-packages will have to care about > characteristics of a package providing a static library. > > This doesn't make any sense to me on the client-side. It is a minor annoyance on the client side, but the client side /should/ know if they are linking to anything static. In fact, if they do, they have to be on the initialcc of said static package. It's an extra burden you take on by linking statically. -- Jesse Keating Fedora -- All my bits are free, are yours?
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
