Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packaging for Inclusion in Fedora Linux #1

Open
4 tasks
cottsay opened this issue Aug 30, 2017 · 3 comments
Open
4 tasks

Packaging for Inclusion in Fedora Linux #1

cottsay opened this issue Aug 30, 2017 · 3 comments

Comments

@cottsay
Copy link

cottsay commented Aug 30, 2017

Hi!

This package is a candidate for inclusion as an official package in Fedora Linux! Per Fedora packaging guidelines, there are some issues that should be addressed before the package can be officially reviewed, built, and made available in the Fedora RPM repositories.

Since this package is part of a group of packages, I have been prototyping the packages in a Fedora Copr repository [1]. The preliminary sources for this package can be accessed in a Git repository [2].

Here are the initial issues which should be addressed:

  • Official Package Release
    It appears that this package has never released an official version. It would be best if an official version was stamped instead of building "snapshots" of the sources.
  • .SO Name Versioning
    Fedora guidelines strongly suggest that the version be included in any shared object libraries distributed in the package [3]. Some packages in this collection appear to be setting the SONAME value, though the value doesn't match the version of the package.
  • Installation Directory Override
    Any files installed by the packages must conform to Fedora's filesystem hierarchy. In order for this package to install the files as such, it must not override CMake's default install locations without any mechanism to change them. I have sketched out a preliminary patch to address this [4]. Please feel free to use those changes as you see fit.
  • xlocale.h
    This header file was recently removed from glibc. The package built successfully when I switched to locale.h instead [5], but I'm not sure if this is the right thing to do.

Once we have at least acknowledged each of the above issues, I'll initiate the review. If there is a valid reason that any of the issues can't be addressed, please let me know and we'll talk about an FPC exemption. If you have any further questions, or if there is anything I can do to help, please reach out.

Thanks very much!

--scott

[1] https://copr.fedorainfracloud.org/coprs/cottsay/potassco
[2] http://copr-dist-git.fedorainfracloud.org/cgit/cottsay/potassco/libpotassco.git/tree/
[3] https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning
[4] http://copr-dist-git.fedorainfracloud.org/cgit/cottsay/potassco/libpotassco.git/tree/libpotassco-1.0.0-install_dir.patch
[5] http://copr-dist-git.fedorainfracloud.org/cgit/cottsay/potassco/libpotassco.git/tree/libpotassco-1.0.0-xlocale.patch

@BenKaufmann
Copy link
Contributor

Hello Scott,

libpotassco is currently not meant to be used as a standalone shared library.
The (static) library is also not meant to be installed. That's why the option LIB_POTASSCO_INSTALL_LIB
is off by default. Only the application lpconvert should be installed and you can configure the destination via CMAKE_INSTALL_PREFIX and CMAKE_INSTALL_BINDIR.

@cottsay
Copy link
Author

cottsay commented Aug 30, 2017

Hi, Ben.

Thanks for getting back to me. Since libpotassco is used in both clasp and clingo (and maybe other projects too), it would be considered "bundling" to re-build the sources in each downstream package. If you intend for this library to only ever be available as a static lib, a change should be made to specify that in the CMakeLists.txt, at which point .SO Name versioning would be irrelevant. At that point, I think the path of least resistance would be to package this library as a static library in Fedora. That would result in less push-back than bundling the sources, I think. What are your thoughts?

Thanks,

--scott

@BenKaufmann
Copy link
Contributor

Hi Scott.
I updated the cmake files in the dev branch.
Install include and lib directories are now configurable via
${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_INCLUDEDIR}
and
${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}
(https://cmake.org/cmake/help/v3.3/module/GNUInstallDirs.html)
The final part is stil fixed to potassco-${LIB_POTASSCO_VERSION}, though.
Is this a problem?

I also added the .so version property if one decides to build a shared library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants