Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#64505 - [glslang] .cmake files pollute /lib/cmake

Attached to Project: Arch Linux
Opened by Alexandre Demers (oxalin) - Friday, 15 November 2019, 04:29 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Monday, 02 December 2019, 10:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Since 7.13.3496, new .cmake files were introduced to the package. While it could be fine to put them directly under /lib/cmake/, it would be better to have them under a common folder as it is done for all the other packages that install .cmake files.

By the way, I'm the maintainer of lib32-glslang under AUR. If the files are moved to a specific folder, I'll have to mirror it under /lib32/cmake.


Additional info:
* package version(s): 7.13.3496


Steps to reproduce:
Install the package and have a look under /lib/cmake to see how the files are installed compared to the ones from other packages.
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Monday, 02 December 2019, 10:38 GMT
Reason for closing:  No response
Comment by Alexandre Demers (oxalin) - Friday, 15 November 2019, 04:33 GMT
Sorry, it's not under /lib/cmake, but under /usr/lib/cmake.
Comment by Alexandre Demers (oxalin) - Tuesday, 19 November 2019, 17:55 GMT
See this commit for partial fix (the files are dropped directly under ./cmake and not under their own common folder). https://github.com/mattst88/glslang/commit/bd69a4fb1206c3441ed56a9a058adfb6e46d55a6
Comment by Alexandre Demers (oxalin) - Wednesday, 20 November 2019, 09:33 GMT
You could use this patch I created based on proposed one in glslang's issues: https://aur.archlinux.org/cgit/aur.git/tree/fix-cmake-folder.patch?h=lib32-glslang
Comment by Sven-Hendrik Haase (Svenstaro) - Thursday, 21 November 2019, 03:18 GMT
I don't see a change in the files in my package after applying this patch.
Comment by Alexandre Demers (oxalin) - Thursday, 21 November 2019, 04:45 GMT
I'm not sure I understand what you mean. Either the patch applied correctly and the CMakeLists.txt files are now using ${CMAKE_INSTALL_LIBDIR} instead of the hardcoded lib folder or it didn't apply at all. That being said, if everything went correctly, your .cmake files will be exactly where they were already since ${CMAKE_INSTALL_LIBDIR} is set to /usr/lib for the native x64 package. My patch only mimics commit bd69a4fb applied on top of 7.13.3496.

Now, there is another bug that needs to be fixed upstream (already reported) and I'm waiting to hear from the glslang's developers about it: in which folder(s) under cmake should all the .cmake files be installed. I'll let you know once I'll have an answer.
Comment by Sven-Hendrik Haase (Svenstaro) - Sunday, 24 November 2019, 02:06 GMT
I'm not really sure I should apply this patch. For this particular package, everything works fine with the hardcoded path and it doesn't fix the cluttering. The way I see it, this package installs as intended by upstream and the paths are "fine". I agree that it litters the filesystem in a bad way and I'd like to see that changed. I suggest you only apply this patch to your package for the time being to fix lib to lib32.

Since it's merged to upstream master, it'll be in the next release and you could then drop the patch from your own package. Could you link the discussion about the clutter?

Loading...