Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: curry - Münster Curry compiler https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194011 ------- Additional Comments From rc040203@xxxxxxxxxx 2006-06-07 02:17 EST ------- (In reply to comment #2) > (In reply to comment #1) > > I do see this massive static library: > > 19435080 Jun 6 13:23 /usr/lib64/curry/libcurry_g.a that I suppose is simply > > linked to every application. > > > > Now, static libs are really strongly disliked in Extras, so I'm going to need to > > ask for some guidance here. > This is in fact similar to ghc package itself, which contains a lot > of static libraries. I think, therefore, it is ok. Without having looked into the details lib*_g.a indicates a static-debug variant of a library. This is problematic twice: static + debug. If "static" isn't avoidable (This often is the case for exotic compilers), then package it ... "debug" is a different issue: Such libaries are rarely needed by anybody and often are of doubtful benefits. One would have to check for for what they are really needed and if shipping a "non-debug variant" isn't sufficient. In most cases a "-O2 -g" compiled "non-debug" variant + debug-info-rpms render "debug variants" superfluous. But with exotic compilers, one never knows. So I recommend to check for * if it is really required and if a non-debug variant + debuginfos are sufficient. * if existance of this file is mandatory for the toolchain. If not, I'd recommend removing it, or packaging it into a separate *-debug package (cf. how gcc and glibc are being packaged). If yes, if this library can't be replaced with a set of "lib*_g.a -> lib*.a" symlinks (This approach is used by newlib. It supports a *_g.a libs but by default doesn't build it, and therefore needs these links) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review