Conan-center-index: [question] Package layout restrictions

[mmha]

I'm currently packaging patchelf, but I'm a bit unhappy with the restrictions on the package layout (KB-H013).

• license directory: I think there should be subdirectories per package the licenses refer to. For easy deployment of a set of packages I've written a custom generator that generates a union of all package trees. This works well for most packages, except for the license files, which often collide. I'd prefer if we stick with prior art and put the licenses in share/licenses/<package-name> like Arch or share/doc/<package-name>/copyright like Ubuntu.

• Man pages: patchelf comes with a manpage and it would make sense to ship it and append MANDIR in package_info. HIER(7) recommends to put man pages in share/man and the build script puts it there, already, but KB-H013 has no notion of share/.

* "Stick everything in bin". This is not always possible. Many packages put internal applications in libexec to keep them private and to avoid name clashes. For example, a custom compiler might decide to move its linker there to avoid the linker accidentally overriding the system linker when using the system compiler. Qt applications often have a hardcoded custom (relative) search path for plugins and QML modules.

I tihnk I'd prefer if the rule is dropped and packagers are advised to keep the packages as vanilla as possible. Not only because of edge cases that would just end up in fragile patches or post-install steps unknown to the build system being applied, but also to stick with existing conventions in Linux distributions. CMake config files and pkg-config files expect certain files to be at a certain relative location.

In the future I'd like to be able to write custom generators for DEB, RPM and Arch packages and I'd rather avoid reverting Conan-isms while generating a package.

[danimtb]

Hi @mmha!

Thanks for sharing your thoughts. We thought previously about the package folder layouts and the restrictions to apply to the conan-center-index recipes and we agreed to follow a simple and general convention.

I understand your points and I think there is room for discussion. However, I believe this is something that should be included first in the Conan cpp_info model. If licenses location, man pages and "libexec" binaries are important, Conan generators should know about them in order to use them and use the information as input for consumers.

We have released the service on top of the existing Conan features and we will work to incorporate the upcoming ones to recipes if they provide good value for the Conan community. Meanwhile, we will have to use the actual model and apply the conventions to make contributions easier and to improve the consumer experience of packages generated under this build service.

Please feel free to open an issue about this in conan-io/conan repository to involve anyone interested in these additions to the model. Thanks 😄

[grafikrobot]

Not so funnily I'm also running to issues while packaging modular Boost regarding the layout restrictions. And reengineering the packages to kludge around the restrictions is going to be highly time consuming, and not a welcomed endeavor.

[danimtb]

Closing this issue as no further action will be taken without an improvement on the cpp_info model in Conan itself. Thanks for your understanding and do not hesitate to open a new issue with new questions.