Hide Forgot
Created attachment 1148026 [details] new spec adds dynamic version as extra rpm Description of problem: As the summary says, the devel package only contains a static linkable version for this library. There are other software applications, not included in Fedora database, that load this library dynamically, several cross compilers do that. Version-Release number of selected component (if applicable): 2.5.39 How reproducible: Use a program which loads the library dynamically. Additional info: modified the spec file from the srpm and made "flex-dynamic" (*.so files) and a "flex-extra" (*.la files) packages.
Hi, I have been reviewing the Fedora Packaging Guidelines to understand the correct way to add the .so and .la files. https://fedoraproject.org/wiki/Packaging:Guidelines Under "Packaging Static Libraries" it states that: Libtool archives, foo.la files, should not be included.... My understanding is that users of libtool can generate the .la files as needed. Is that correct? I have implemented changes to support the .so files in compliance with the Fedora Packaging Guidelines. These changes are being reviewed now and will be available as soon as the review is completed. I appreciate your patience with this matter. Please let me know if you have any questions or concerns. Thank You, Patsy
Frankly I do not know about the .la files, I was missing the .so and I've said to myself, why not package the .la separately as they are probably needed by someone. Still, there is no reason to leave out .so files, those are the actual libraries that programs link to.
Hi, I'm sorry that this impacted you. Per the Packaging Guidelines, adding the .so files will require adding an additional sub-package. We try not to add new sub-packages unless there is an actual demand for them. Until your request, we had not had any requests to ship .so files with flex Therefore, we decided not ship them. We will be releasing the new sub-packages very soon. I will be sure to update this BZ once they are available. Thanks for your patience, Patsy
Fwiw, doing this right will likely mean reverting the change for bug #674301 , where flex-devel will provide the shlib links, and -static will provide only the static lib
Rex, That's been part of the delay getting this out. We want to make sure we adhere to the packaging requirements but not break existing installs. The current plan is as follows: flex-static contains the static libraries flex-runtime contains the versioned .so files (libfl.so.2, libfl.so.2.0.0,..) flex-devel will include the header files and .so files flex-devel will also Require flex-static and flex-runtime Does that sound reasonable? Thoughts? Thanks, Patsy
1. In favor of using -runtime, usual convention is to name the package after the library (libflex) or -libs (flex-libs). 2. -static should depened on -devel, not the other way around (or have to dependency at all, and include the single header file in both -static and -devel)
Sorry, for 1, make that libfl. I'm finding flex's buildsystem odd, that it insists on building both pic and non-pic versions of shared and static libs. Was hoping to just use the default build types instead of hacking -fPIC into CFLAGS. Not sure which approach is less bad. :-/
We currently have the static libraries in flex-devel. Users expect to get the static libraries when they install flex-devel. This is why we require flex-static in flex-devel. We discussed several names for the versioned libraries and opted for -runtime because it was more generic for all "runtime" features. After bumping into the -devel restriction and needing to add more packages, I'd like to leave the option of adding other runtime support to this sub-package. For example, bison uses -runtime for the .mo files.
If -devel is going to require -static, then there's little point in packaging them separately, imo. Just put it all in -devel.
The Fedora Packaging Guidelines state that the -devel package can contain static library files when the package does not provide any matching shared library files. Prior to the .so files being added, we had the static libraries in -devel but now that we have shared libraries, they rightfully belong in the -devel package - but we want to provide for situations where the static libraries are still expected to be in -devel.
This change is pending a review and will be updates ASAP.
Finally looking at this. I'm going to summarize the situation so far (some of it has already been discussed above, e.g. RE packaging guidelines by Patsy): If we are to provide the shared object, then according to the Fedora Packaging Guidelines [1]: 1. flex should contain the application 2. flex-devel should contain the .so 3. flex-static should contain the .a On the other hand, it's been a few years that we have been shipping: 1. flex - with the application 2. flex-devel - with the .a, while also providing flex-static via a virtual "Provides" This is correct as per the packaging guidelines for packages that only provide a static library. Questions and answers: * What is the impact of creating a flex-static with .a, and providing the .so in flex-devel? - Packages needing to link against the .a are expected to BuildRequire flex-static and not flex-devel (if they are built as per the packaging guidelines). If they do, then ideally, packagers should be surprised by us creating a flex-static and moving the .a to it. - Users might be surprised, though, if they installed flex-devel and suddenly it doesn't provide the .a any more. * What are other distros doing? - Debian [2] as a flex, libfl2 with the .so, and libfl-dev with the .a. So they also provide separate packages with the shared and static libraries. * What is the demand for the .so? - Is there a way to gauge this? Of course, the reporter found themselves wanting it so that's one data point. Happy for more input or corrections. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries [2] https://packages.debian.org/source/sid/flex
FWIW this is a paraphrasing of the full contents of libfl: int yywrap(void) { return 1; } int main(...) { while (yylex () != 0) ; exit(0); } The reason this was never shipped as a DSO is that it's such a trivial code. I find it odd that some tool out there would find it necessary to dlopen this. That said, nothing prevents shipping the DSO. That is apparently what other distros are doing, and it is also what other libraries in Fedora do. So principle of least surprise indicates flex should be like that as well. And those odd tools out there evidently do exist ^o^.
Thanks, Petr. Yes, Debian and SUSE provide the DSO, so like you said: the principle of least surprise indicates that this is the best course. I recently discussed this with Carlos, and I'll be adjusting the subpackages to provide the DSO. I'll also adjust naming to fall in line with Debian and SUSE naming, and set up virtual provides for the old names. While we are at it, it also seemed worth it to look at packages that incorrectly require flex-devel today. flex-devel only provides the static library and as per packaging guidelines, packages that have a build dependency on the static archive are supposed to depend on flex-static (which we virtually provide today). Here is the list: $ dnf repoquery --disablerepo="*" --enablerepo="*-source" --arch=src --whatdepends flex-devel Last metadata expiration check: 0:00:37 ago on Thu 20 Aug 2020 11:40:54 CEST. bsd-games-0:2.17-62.fc32.src genesis-simulator-0:2.4-5.20181209git374cdbc.fc32.src neuron-0:7.7.2-1.fc32.src neuron-0:7.7.2-7.fc32.src python-biopython-0:1.76-2.fc32.src thrift-0:0.13.0-3.fc32.src usbsniff-0:0-12.20141209git079747e.fc32.src vhd2vl-0:2.5-10.fc32.src wide-dhcpv6-0:20080615-13.1.fc32.10.src xorg-x11-server-0:1.20.8-1.fc32.src I plan to file bugs against them informing of the upcoming subpackage changes and the incorrect build dependency they have at present.
I pushed the changes to git: Re-work and rename flex subpackages, and provide shared libraries This resolves a user request for a shared library (#1327851) and harmonizes package names and content with Debian and SUSE. The following subpackage changes have been made: - Remove and obsolete the flex-devel subpackage containing static libraries - Provide shared libraries in a new subpackage named libfl2 - Provide development files in a new subpackage named libfl-devel - Provide static libraries in a new subpackage named libfl-static ...and started building flex-2.6.4-6.fc34 for rawhide. I also filed the following bugs against the components I listed in comment 14: bug 1871089 bug 1871091 bug 1871093 bug 1871095 bug 1871096 bug 1871097 bug 1871098 bug 1871099 bug 1871101
Based on the closure of some of the above bugs I filed, it appears that some build-dependent packages have already transitioned to the correct build dependency.