Bug 1327851

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.