Statically include microsoft-gsl

[fpesari]

Feature Description

Hello,

I am a packager on openSUSE and I've noticed that there is CMake check for an installed version of Microsoft GSL:

find_package(Microsoft.GSL CONFIG)
if(Microsoft.GSL_FOUND)
  target_link_libraries(mixxx-lib PRIVATE Microsoft.GSL::GSL)
else()
  # check if the headers have been installed without cmake config (< 3.1.0)
  check_include_file_cxx(gsl/gsl HAVE_GSL_GSL)
  if(NOT HAVE_GSL_GSL)
    unset(HAVE_GSL_GSL CACHE) # unset cache to re-evaluate this until it succeeds. check_include_file_cxx() has no REQUIRED flag.
    message(FATAL_ERROR "ms-gsl deveopment headers (libmsgsl-dev) not found")
  endif()
endif()

However, from GSL's README it seems that "the entire implementation is provided inline in the headers". Other than being a header-only library, releases are not so frequent (last tag is from Jan 29th, 2022), the size is very small (few KBs) and many distros (including mine, openSUSE) don't package it, so I think it's better to statically include it in mixxx' source tree (lib/) using the installed version only as a fallback.

[uklotzde]

Why don't you then suggest to package it, too? Fedora, Debian/Ubuntu, and Arch do so.

[daschuer]

At least it is packed by 92 Distro Versions: https://repology.org/project/ms-gsl/versions I suggest to add this package to openSUSE as well. For us it would be a maintenance burden to add and maintain it to our lib folder. My guess is that other projects will also rely on the availability so it will be a win for them as well. Would this be doable for you?

[atskler]

@daschuer approx +80% of that 92 distro is basically just 2-3: Debian, Arch, and Fedora. If we would like to think in independent and not derivative distributions.

[uklotzde]

@daschuer approx +80% of that 92 distro is basically just 2-3: Debian, Arch, and Fedora. If we would like to think in independent and not derivative distributions.

...which probably represents the great majority when measured in number of users.

This is a commonly used library and there is reason why these distributions decided to package it.

[atskler]

@uklotzde yet I'm afraid it is sill a poor response. On my part I can understand the NO BS rationale "For us it would be a maintenance burden to add and maintain it to our lib folder." but this war and play with the numbers is pure BS and the favorite toy of politicians.

[daschuer]

@atskler: The original question was: Would is be doable for you to port one of the existing rpm packages to openSUSE? Another alternative would be to download the files to your build machine as part of your packaging receipt.

[atskler]

@daschuer And from the standpoint of a simple user - on the most usable rolling release distribution - one have to fiddle with things like this and can’t just use a software.

For this software use Debian and derivatives, for that the Fedora, and for another stuff the Arch,… Because here only this way, there only that way supported, and the current fad distro... And at the end all this resembles to the phenomenon of vendor lock-in.

Everyone says: the other one should implement it.

I don’t have the knowledge and the power to implement it on either end.

[daschuer]

As a simple user, can't you just use the Fedora rpm or download and copy the gsll files into you include folder?

[atskler]

@daschuer only just as a MacGyver. But I'm afraid I have to contact Peter Thornton because I'm not that MacGyver...

[uklotzde]

Everyone says: the other one should implement it.

It would be easy for Mixxx to add it in the first place (ignoring any long-term maintenance burden). Much easier and faster than to convince the openSUSE maintainers to package it. Nevertheless, it would be the wrong decision.

[daschuer]

Oh I have picked the wrong @ mention yesterday, sorry.

@atskler: Since ms-gls is only a build dependency, a normal user will not even bothered with this issue.

@fpesari: Would is be doable for you to port one of the existing rpm packages to openSUSE? Another alternative would be to download the files to your build machine as part of your packaging receipt.

[fpesari]

OK, let me add some detail to my OP, so that the rationale for my request is clearer.

I help maintain a repository for audio-related software, multimedia:proaudio. microsoft-gsl is not an audio package, so I can't simply push it into that repository, I'd either have to go through all the hoops required for system libraries, which are hosted in a different repository ran by different people, devel:libraries:c_c++ or bundle microsoft-gsl into Mixxx myself.

If microsoft-gsl were audio-related, I would have no problem packaging it. I made my request because I concluded that microsoft-gsl was a header-only, small and relatively stable non-audio library and I thought that statically including it would not cost a lot in term of maintenance. If it can create problems, the copy in lib/ can always be used as a fallback while the system library is used by default, so that most users aren't affected (but given that some distros like Ubuntu are not rolling, it may happen that Mixxx would ship the most up-to-date version).

If I made a wrong assumptions, I apologize. I just wanted to find a solution that works for everyone.

[fpesari]

@fpesari: Would is be doable for you to port one of the existing rpm packages to openSUSE? Another alternative would be to download the files to your build machine as part of your packaging receipt.

openSUSE is not a Fedora derivative and we have working RPM .specs (here). I don't even maintain Mixxx myself (if you notice, it's in another repository, multimedia:apps) but I was told about this issue and decided to report it since I saw that Mixxx already had a lib/ directory containing some libs.

If you insist that my request is impossible to satisfy, we could:

1. Try getting microsoft-gsl into openSUSE, but it may take a long time (if it ever happens);
2. Patch Mixxx' build to include microsoft-gsl in lib/ (but maintaining a patch which differs from upstream is something we try to avoid);
3. Install microsoft-gsl only in Mixxx' build environment until (1) happens (but this is not a packaging good practice, IMHO).

The best option in terms of good practices is (1), but until the process finishes we'd have to ship a non-audio library from our audio-related repository, something we really try to avoid to make our repo work well with people's everyday setups.

The problem is not that microsoft-gsl is hard to package on openSUSE, somebody else already did it and we'd just need to push that package to the devel:libraries:c_c++ repo. The problem is that (a) package approval processes may take a very long time and after that, there is (b) another process for getting the package into Factory (the main Tumbleweed repository, which then is fed into Leap). And (a) and (b) could never happen, they could be stopped in their tracks because one of the maintainers thinks microsoft-gsl is not worthy of inclusion in openSUSE (and, being a header-only library, it's a concrete risk).

So I'd personally go with (1) and, in the meanwhile, (3) if you say no. But if you say yes, I think we may be able to ship the latest Mixxx for several months without having to deal with other openSUSE repositories.

[uklotzde]

I consider 2 as a viable alternative before 1 is in place. You could add the sources in the /lib directory and alter a few lines in CMakeLists.txt. Add a comment with a link to the openSUSE packaging request and it would be a maintainable solution that is restricted to the openSUSE context.

As a project Mixxx should not compensate for the deficiencies in other organization's processes like lengthy and controversial packaging decisions.

Someone has to kick off the packaging discussion in openSUSE instead of delegating the burden to other projects as a loophole. Otherwise no one will notice that there is a need for microsoft-gsl nowadays.

[atskler]

@uklotzde "As a project should not compensate for the deficiencies in other organization's processes like lengthy and controversial ing decisions." - Exactly this the motto of our current times, and everywhere and every time I'm being sent away with the like answers. Local government offices, the banks, the shops...

And at the end always I, the simple end user had to compensate for everything... And I'm free to leave...

@daschuer

@atskler: Since ms-gls is only a build dependency, a normal user will not even bothered with this issue.

A normal user will just ignore Mixxx altogether after trying it and founding it erratic here and there.

Usually important fixes are not released in a release for months. If you need them, you have to build for yourself from the sources.

Or some fix released in a new release with other fixes and additional stuff, but it happens to brake a feature worked correctly beforehand. And then you have to build for yourself again until it is fixed, then you can build to check the fix...

[atskler]

Usually important fixes are not released in a release for months. If you need them, you have to build for yourself from the sources.

Or some fix released in a new release with other fixes and additional stuff, but it happens to brake a feature worked correctly beforehand. And then you have to build for yourself again until it is fixed, then you can build to check the fix...

And here it is the next issue in v2.3.4 and in the main: https://github.com/mixxxdj/mixxx/issues/11341

So again, one must downgrade v2.3.4 to a working point and build it for himself, if he is badly affected by the problem, if one's distro/repo updated Mixxx for him. And again, probably weeks and months for the fix and for the release with the fix.

[uklotzde]

@atskler As an ordinary developer who is no longer involved in the project I kindly ask you to stay focused on the topic. Please avoid general accusations. Thank you.