Bug 1748233
Summary: | Review Request: pgloader - Data loading tool for PostgreSQL | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lukas Javorsky <ljavorsk> |
Component: | Package Review | Assignee: | Miroslav Suchý <msuchy> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 30 | CC: | mschorm, msuchy, package-review |
Target Milestone: | --- | Flags: | msuchy:
fedora-review?
|
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-04-22 11:40:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 177841 |
Description
Lukas Javorsky
2019-09-03 08:07:58 UTC
Description fixed: Data loading tool that allows to implement continuous migration from current database to PostgreSQL. It uses the COPY PostreSQL protocol to stream the data into the server. Pgloader can read data from CSV and DBF files, or SQLite, MySQL, MS SQL Server, PostgreSQL, Redshift databases. I will do this one. Please always provide links to the raw version of files. - If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. Note: No gcc, gcc-c++ or clang found in BuildRequires See: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ Please address these - we discussed that in person: pgloader.x86_64: E: devel-dependency openssl-devel pgloader.x86_64: E: wrong-script-interpreter /usr/share/doc/pgloader/docs/conf.py /usr/bin/env python3 pgloader.x86_64: W: no-manual-page-for-binary pgloader Hmm, I am really woried about those bundles in tarball - all those pgloader-bundle-3.6.1/software/* Instead of that you have to use normal libraries and packages in Fedora. And if they do not exists there yet, they need to be packaged separately. Updated URLS: Spec URL: https://raw.githubusercontent.com/ljavorsk/pgloader/master/pgloader.spec SRPM URL: https://github.com/ljavorsk/pgloader/raw/master/pgloader-3.6.1-1.fc30.src.rpm pgloader.x86_64: E: devel-dependency openssl-devel - this dependency is needed as we spoke about it becasue of /usr/lib64/libcrypto.so pgloader.x86_64: E: wrong-script-interpreter /usr/share/doc/pgloader/docs/conf.py /usr/bin/env python3 - fixed, don't include the docs/ directory at all pgloader.x86_64: W: no-manual-page-for-binary pgloader - python-sphinx generated man pages from docs/ directory So it means, that it can't use it like this, and require every package there, or package them if needed? (In reply to Miroslav Suchý from comment #3) > > Hmm, I am really woried about those bundles in tarball - all those > pgloader-bundle-3.6.1/software/* Instead of that you have to use normal > libraries and packages in Fedora. And if they do not exists there yet, they > need to be packaged separately. In theory yes - all of the requirements should be also separately packed, prior to this package. However I see two main obstructions here. 1) The program is written in such a way, the Common LISP download the libraries at runtime (really, by curl). * The libraries are mostly latest push in the master branch of the project. * To resolve this and make things safer (different library version each run), we need to get them prior the runtime - either pack them, or bundle them. * The upstream release the bundle with specific library versions and marks this as a recommended way to pack the application to various OS. 2) There are ~70 LISP libraries in that bundle. Between following stable versions (of pgloader), most of them are updated to another specific version, so it would be hard to manage them packed separately. Given that that specific set of versions of those libraries is supported and tested configuration by the upstream, I'd stick to it for now. Do you agree? In that case, it needs to follow https://fedoraproject.org/wiki/Bundled_Libraries#Requirement_if_you_bundle Can you talk to upstream about not bundling or at least supporting building against shared versions of the libraries? Sorry for late update. Upstream won't change the bundled libraries, so after a talk with msuchy, we've agreed on not to package this one. It would be really difficult to watch every bundle, after every upstream's update. This BZ can be closed now. |