Hide Forgot
Description of problem: libfl.a from flex-static is need to compile simple flex code, but the x86_64 repo doesn't contain the i686 build of flex-static. Version-Release number of selected component (if applicable): 14 How reproducible: 100% Steps to Reproduce: 1.Compile and link a simple flex program that links to -lfl using gcc -m32. 2.Look in the repo with yum list flex-static Actual results: 1. /usr/bin/ld: skipping incompatible /usr/lib64/libfl.a when searching for -lfl /usr/bin/ld: cannot find -lfl 2. Loaded plugins: presto, refresh-packagekit Installed Packages flex-static.x86_64 2.5.35-11.fc14 @anaconda-InstallationRepo-201010211827.x86_64 Expected results: 1. It should be linking with /usr/lib/libfl.a. 2. Should show flex-static.i686 as being available as well. Additional info: flex-static is different from other static libraries because it provides something that isn't in any .so library, so I think that is a reason to put it in the repo. Obtaining and installing the flex-static.i686 package from the i386 repo works.
flex-static should provide, or be named, flex-devel, I believe. See https://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy: 2. Static libraries only. When a package only provides static libraries you can place all the static library files in the *-devel subpackage. When doing this you also must have a virtual Provide for the *-static package: %package devel Provides: foo-static = %{version}-%{release}
So, are we blacklisting -static packages, or what's the reason? That point says "you can", and it seems more correct having it in -static when, in fact, it's exclusively static libraries that we provide.
The situation is still the same. flex-static is provided for the major architecture, but is missing in minor architecture (verified on x86_64 and ppc64). If the sub-package rename is necessary to make static libraries visible in distribution, then so be it, otherwise I don't see a reason to do it.
We do multilib for development packages, keying off the -devel package name. Given that in other cases we've been requested to not ship the static libs as a compat arch package when we have dynamic equivalents, bringing in all -static packages seemed wrong. If it's named flex-devel, it will get pulled in.
Would just providing flex-devel instead of renaming the subpackage have the same effect?
No.
I've renamed the package with corresponding Obsoletes: and Provides: rules so that clients can request flex-static as before.